...
The Simple Expression Language is was a really simple language you can use. Its when it was created, but has since grown more powerful. It is primarily intended for being a really small and simple language for testing evaluating Expressions and Predicates without requiring any new dependencies or knowledge of XPath; so its it is ideal for testing in camel-core
. The idea was to cover 95% of the common use cases when you need a little bit of expression based script in your Camel routes.
However for real world much more complex use cases you are generally recommended to choose a more expressive and powerful language such as:
- SpEL
- Mvel
- Groovy
- JavaScriptBean Language
- EL
- OGNL
- one of the supported Scripting Languages
The simple language uses ${body
} placeholders for complex expressions where the expression contains constant literals. The $
Deprecated: The ${}
placeholders can be omitted if the expression starts with the token, or if the token is only the token itself.
To get the body of the in message: "body"
, or "in.body"
or "${body}"
.
A complex expression must use ${ } placeholders, such as: "Hello ${in.header.name} how are you?"
.
You can have multiple tokens in the same expression: "Hello ${in.header.name} this is ${in.header.me} speaking"
.
However you can not nest tokens (i.e. having another ${ } placeholder in an existing, is not allowed).
...
From Camel 2.5 you can also use the alternative syntax which uses $simple{}
as placeholders. This can be used in situations to avoid clashes when using for example Spring property placeholder together with Camel.
...
From Camel 2.8 you can configure the result type of the Simple expression. For example to set the type as a java.lang.Boolean
or a java.lang.Integer
etc.
...
From Camel 2.2
...
, the File Language is now merged with Simple language which means you can use all the file syntax directly within the simple language.
Variables
...
Variable
...
Type
...
Description
...
id
...
String
...
the input message id
...
body
...
Object
...
the input body
...
in.body
...
Object
...
the input body
...
body.OGNL
...
Object
...
Camel 2.3: the input body invoked using a Camel OGNL expression.
...
in.body.OGNL
...
Object
...
Camel 2.3: the input body invoked using a Camel OGNL expression.
...
bodyAs(type)
...
Type
...
Camel 2.3: Converts the body to the given type determined by its classname
...
out.body
...
Object
...
the output body
...
header.foo
...
Object
...
refer to the input foo header
...
headers.foo
...
Object
...
refer to the input foo header
...
in.header.foo
...
Object
...
refer to the input foo header
...
in.headers.foo
...
Object
...
refer to the input foo header
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="780493fd-2d22-4f3c-b0ce-cdcf02b187cc"><ac:plain-text-body><![CDATA[
...
header.foo[bar]
...
Object
...
Camel 2.3: regard input foo header as a map and perform lookup on the map with bar as key
...
]]></ac:plain-text-body></ac:structured-macro>
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="342a6b4c-7188-42b1-9913-33bd23e92c11"><ac:plain-text-body><![CDATA[
...
in.header.foo[bar]
...
Object
...
Camel 2.3: regard input foo header as a map and perform lookup on the map with bar as key
...
]]></ac:plain-text-body></ac:structured-macro>
...
The Simple language have been improved from Camel 2.9 to use a better syntax parser, which can do index precise error messages, so you know exactly what is wrong and where the problem is. For example if you have made a typo in one of the operators, then previously the parser would not be able to detect this, and cause the evaluation to be true. There are a few changes in the syntax which are no longer backwards compatible. When using Simple language as a Predicate then the literal text must be enclosed in either single or double quotes. For example: "${body} == 'Camel'"
. Notice how we have single quotes around the literal. The old style of using "body"
and "header.foo"
to refer to the message body and header is @deprecated
, and it is encouraged to always use ${}
tokens for the built-in functions.
The range operator now requires the range to be in single quote as well as shown: "${header.zip} between '30000..39999'"
.
To get the body of the in message: body
, or in.body
or ${body}
.
A complex expression must use ${}
placeholders, such as: Hello ${in.header.name} how are you?
.
You can have multiple functions in the same expression: "Hello ${in.header.name} this is ${in.header.me} speaking"
. However you can not nest functions in Camel 2.8.x or older e.g., having another ${}
placeholder in an existing, is not allowed. From Camel 2.9 you can nest functions.
Variables
...
Variable | Type | Description |
---|---|---|
|
| Camel 2.10: the CamelContext name. |
|
| Camel 2.11: the |
|
| Camel 2.17: The collate function iterates the message body and groups the data into sub lists of specified size. This can be used with the Splitter EIP to split a message body and group/batch the split sub messages into a group of |
|
| Camel 2.16: the Exchange. |
|
| Camel 2.16: the Exchange invoked using a Camel OGNL expression. |
|
| Camel 2.3: the exchange Id. |
|
| The input message Id. |
|
| The input body. |
|
| The input body. |
|
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="2fe296f9-8e8b-454a-baa5-158cb700a987"><ac:plain-text-body><![CDATA[
...
| Camel 2.3: |
...
]]></ac:plain-text-body></ac:structured-macro>
...
the input body invoked using a Camel OGNL expression. |
|
...
|
| Camel 2.3: |
...
the input |
...
body invoked using a Camel OGNL expression. |
...
in.header.foo.OGNL
...
|
|
...
Camel 2.3: |
...
Converts the body to the |
...
given type determined by its classname. The converted body can be |
|
...
|
| Camel 2. |
...
18: |
...
Converts the body to the |
...
given type determined by its classname and then invoke methods using a Camel OGNL expression. |
...
out.header.foo
...
Object
...
refer to the out header foo
...
out.headers.foo
...
Object
...
refer to the out header foo
...
The converted body can be | ||
|
| Camel 2.5: Converts the body to the given type determined by its classname, and expects the body to be not |
|
| Camel 2.18: Converts the body to the given type determined by its classname and then invoke methods using a Camel OGNL expression. |
|
| The output body. |
|
...
|
|
...
Refer to the |
...
input | ||
|
| Camel 2.9.2: refer to the input |
|
...
|
...
|
...
Refer to the |
...
sysenv.foo
...
input | |
|
|
...
Camel 2. |
...
9.2: refer to the |
...
exception.message
...
String
...
Camel 2.0. Refer to the exception.message on the exchange, is null if no exception set on exchange. Will fallback and grab caught exceptions (Exchange.EXCEPTION_CAUGHT
) if the Exchange has any.
...
date:command:pattern
...
String
...
Camel 1.5. Date formatting using the java.text.SimpleDataFormat
patterns. Supported commands are: now for current timestamp, in.header.xxx or header.xxx to use the Date object in the IN header with the key xxx. out.header.xxx to use the Date object in the OUT header with the key xxx.
...
bean:bean expression
...
Object
...
Camel 1.5. Invoking a bean expression using the Bean language. Specifying a method name you must use dot as separator. In Camel 2.0 we also support the ?method=methodname syntax that is used by the Bean component.
...
properties:locations:key
...
String
...
Camel 2.3: Lookup a property with the given key. The locations
option is optional. See more at Using PropertyPlaceholder.
OGNL support
Available as of Camel 2.3
The Simple and Bean language now supports a Camel OGNL notation for invoking beans in a chain like fashion.
Suppose the Message IN body contains a POJO which has a getAddress()
method.
Then you can use Camel OGNL notation to access the address object:
Code Block |
---|
simple("${body.address}")
simple("${body.address.street}")
simple("${body.address.zip}")
|
Camel understands the shorthand names for getters, but you can invoke any method or use the real name such as:
Code Block |
---|
simple("${body.address}")
simple("${body.getAddress.getStreet}")
simple("${body.address.getZip}")
simple("${body.doSomething}")
|
You can also use the elvis operator (?.
) to avoid NPE if for example the body does NOT have an address
Code Block |
---|
simple("${body?.address?.street}")
|
Its also possible to index in Map
or List
types, so you can do:
Code Block |
---|
simple("${body[foo].name}")
|
To assume the body is Map
based and lookup the value with foo
as key, and invoke the getName
method on that value.
Suppose there was no value with the key foo
then you can use the elvis operator to avoid the NPE as shown:
Code Block |
---|
simple("${body[foo]?.name}")
|
You can also access List
types, for example to get lines from the address you can do:
Code Block |
---|
simple("${body.address.lines[0]}")
simple("${body.address.lines[1]}")
simple("${body.address.lines[2]}")
|
And yes you can combine this with the operator support as shown below:
Code Block |
---|
simple("${body.address.zip} > 1000")
|
Operator support
Available as of Camel 2.0
We added a basic set of operators supported in the simple language in Camel 2.0. The parser is limited to only support a single operator.
To enable it the left value must be enclosed in ${ }. The syntax is:
Code Block |
---|
${leftValue} OP rightValue
|
Where the rightValue
can be a String literal enclosed in ' '
, null
, a constant value or another expression enclosed in ${ }.
Camel will automatically type convert the rightValue type to the leftValue type, so its able to eg. convert a string into a numeric so you can use > comparison for numeric values.
The following operators is supported:
Operator | Description |
---|---|
== | equals |
> | greater than |
>= | greater than or equals |
< | less than |
<= | less than or equals |
!= | not equals |
contains | For testing if contains in a string based value |
not contains | For testing if not contains in a string based value |
regex | For matching against a given regular expression pattern defined as a String value |
not regex | For not matching against a given regular expression pattern defined as a String value |
in | For matching if in a set of values, each element must be separated by comma. |
not in | For matching if not in a set of values, each element must be separated by comma. |
is | For matching if the left hand side type is an instanceof the value. |
not is | For matching if the left hand side type is not an instanceof the value. |
range | For matching if the left hand side is within a range of values defined as numbers: |
not range | For matching if the left hand side is not within a range of values defined as numbers: |
And the following operators can be used to group expressions:
Operator | Description |
---|---|
and | and is used to group two expressions |
or | or is used to group two expressions |
Notice: Currently and
or or
can only be used once in a simple language expression. This might change in the future.
The syntax for AND is:
Code Block |
---|
${leftValue} OP rightValue and ${leftValue} OP rightValue
|
And the syntax for OR is:
Code Block |
---|
${leftValue} OP rightValue or ${leftValue} OP rightValue
|
Some examples:
Code Block |
---|
simple("${in.header.foo} == 'foo'")
// ' ' can be omitted
simple("${in.header.foo} == foo")
// here Camel will type convert '100' into the type of in.header.bar and if its an Integer '100' will also be converter to an Integer
simple("${in.header.bar} == '100'")
simple("${in.header.bar} == 100")
// 100 will be converter to the type of in.header.bar so we can do > comparison
simple("${in.header.bar} > 100")
// testing for null
simple("${in.header.baz} == null")
// testing for not null
simple("${in.header.baz} != null")
|
And a bit more advanced example where the right value is another expression
Code Block |
---|
simple("${in.header.date} == ${date:now:yyyyMMdd}")
simple("${in.header.type} == ${bean:orderService?method=getOrderType}")
|
And an example with contains, testing if the title contains the word Camel
Code Block |
---|
simple("${in.header.title} contains 'Camel'")
|
And an example with regex, testing if the number header is a 4 digit value:
Code Block |
---|
simple("${in.header.number} regex '\d{4}'")
|
And finally an example if the header equals any of the values in the list. Each element must be separated by comma, and no space around.
This also works for numbers etc, as Camel will convert each element into the type of the left hand side.
Code Block |
---|
simple("${in.header.type} in 'gold,silver'")
|
And for all the last 3 we also support the negate test using not:
Code Block |
---|
simple("${in.header.type} not in 'gold,silver'")
|
And you can test for if the type is a certain instance, eg for instance a String
Code Block |
---|
simple("${in.header.type} is 'java.lang.String'")
|
We have added a shorthand for all java.lang
types so you can write it as:
Code Block |
---|
simple("${in.header.type} is String")
|
Ranges is also supported. The range interval requires numbers and both from and end is inclusive. For instance to test whether a value is between 100 and 199:
Code Block |
---|
simple("${in.header.number} range 100..199")
|
Notice we use ..
in the range without spaces. Its based on the same syntax as Groovy.
...
title | Can be used in Spring XML |
---|
As the Spring XML does not have all the power as the Java DSL with all its various builder methods, you had to resort to use some other languages
for testing with simple operators. Now you can do this with the simple language. In the sample below we want to test if the header is a widget order:
...
<from uri="seda:orders">
<filter>
<simple>${in.header.type} == 'widget'</simple>
<to uri="bean:orderService?method=handleWidget"/>
</filter>
</from>
Using and / or
If you have two expressions you can combine them with the and
or or
operator.
For instance:
Code Block |
---|
simple("${in.header.title} contains 'Camel' and ${in.header.type'} == 'gold'")
|
And of course the or
is also supported. The sample example would be:
Code Block |
---|
simple("${in.header.title} contains 'Camel' or ${in.header.type'} == 'gold'")
|
Notice: Currently and
or or
can only be used once in a simple language expression. This might change in the future.
So you cannot do:
Code Block |
---|
simple("${in.header.title} contains 'Camel' and ${in.header.type'} == 'gold' and ${in.header.number} range 100..200")
|
Samples
In the Spring XML sample below we filter based on a header value:
...
input | |||
|
| Refer to the input | |
|
| Camel 2.9.2: refer to the input | |
|
| Refer to the input | |
|
| Camel 2.9.2: refer to the input | |
|
| Camel 2.3: regard input | |
|
| Camel 2.3: regard input | |
|
| Camel 2.3: regard input | |
|
| Camel 2.3: refer to the input | |
|
| Camel 2.3: refer to the input | |
|
| Camel 2.3: refer to the input | |
|
| Refer to the out header | |
|
| Camel 2.9.2: refer to the out header | |
|
| Refer to the out header | |
|
| Camel 2.9.2: refer to the out header | |
|
| Camel 2.5: Converts the header to the given type determined by its classname. | |
|
| Camel 2.9: refer to the input headers. | |
|
| Camel 2.9: refer to the input headers. | |
|
| Deprecated: refer to the | |
|
| Camel 2.15: refer to the | |
|
| Deprecated: refer to the | |
|
| Camel 2.15: refer to the | |
|
| Deprecated: refer to the | |
|
| Camel 2.15: refer to the | |
|
| Refer to the system property | |
|
| Camel 2.3: refer to the system environment property | |
|
| Camel 2.4: Refer to the exception object on the exchange, is | |
|
| Camel 2.4: Refer to the exchange exception invoked using a Camel OGNL expression object | |
|
| Refer to the exception.message on the exchange, is null if no exception set on exchange. Will fallback and grab caught exceptions ( | |
|
| Camel 2.6. Refer to the | |
|
| Date formatting using the
| |
|
| Invoking a bean expression using the Bean language. Specifying a method name you must use dot as separator. We also support the | |
|
| Deprecated: (use properties-location instead) Camel 2.3: Lookup a property with the given key. The | |
|
| Camel 2.14.1: Lookup a property with the given key. The | |
|
| Camel 2.14.1: Lookup a property with the given key. If the key does not exists or has no value, then an optional default value can be specified. | |
|
| Camel 2.11: Returns the Id of the current route the Exchange is being routed. | |
|
| Camel 2.3: Returns the name of the current thread. Can be used for logging purpose. | |
|
| Camel 2.6: To lookup a bean from the Registry with the given Id. | |
|
| Camel 2.11: To refer to a type or field by its FQN name. To refer to a field you can append | . |
|
| Camel 2.12.3: represents a | |
|
| Camel 2.16.0: returns a random Integer between | |
|
| Camel 2.16.0: returns a random Integer between min (included) and max (excluded) | |
|
| Camel 2.19: The skip function iterates the message body and skips the first number of items. This can be used with the Splitter EIP to split a message body and skip the first N number of items. | |
|
| Camel 2.17: The message history of the current exchange how it has been routed. This is similar to the route stack-trace message history the error handler logs in case of an unhandled exception. | |
|
| Camel 2.17: As |
OGNL expression support
Available as of Camel 2.3
...
Camel's OGNL support is for invoking methods only. You cannot access fields.
From Camel 2.11.1: we added special support for accessing the length field of Java arrays.
The Simple and Bean language now supports a Camel OGNL notation for invoking beans in a chain like fashion. Suppose the Message IN
body contains a POJO which has a getAddress()
method.
Then you can use Camel OGNL notation to access the address object:
...
Camel understands the shorthand names for accessors, but you can invoke any method or use the real name such as:
...
You can also use the null safe operator (?.
) to avoid a NPE if for example the body does not have an address
...
It is also possible to index in Map
or List
types, so you can do:
...
To assume the body is Map
based and lookup the value with foo
as key, and invoke the getName
method on that value.
...
If the key has space, then you must enclose the key with quotes, for example:
...
You can access the Map
or List
objects directly using their key name (with or without dots) :
...
Suppose there was no value with the key foo
then you can use the null safe operator to avoid a NPE as shown:
...
You can also access List
types, for example to get lines from the address you can do:
...
There is a special last
keyword which can be used to get the last value from a list.
...
And to get the penultimate line use subtraction. In this case use last-1
for this:
...
And the third last is of course:
...
And you can call the size
method on the list with
...
From Camel 2.11.1 we added support for the length field for Java arrays as well. Example:
...
And yes you can combine this with the operator support as shown below:
...
Operator Support
The parser is limited to only support a single operator. To enable it the left value must be enclosed in ${}
.
The syntax is:
...
Where the rightValue
can be a String
literal enclosed in ' '
, null
, a constant value or another expression enclosed in ${}
.
...
There must be spaces around the operator.
Camel will automatically type convert the rightValue
type to the leftValue
type, so it is possible to for example, convert a string into a numeric so you can use >
comparison for numeric values.
The following operators are supported:
Operator | Description |
---|---|
| Equals. |
| Camel 2.16: equals ignore case (will ignore case when comparing |
| Greater than. |
| Greater than or equals. |
| Less than. |
| Less than or equals. |
| Not equals. |
| For testing if contains in a string based value. |
| For testing if not contains in a string based value. |
| For matching against a given regular expression pattern defined as a |
| For not matching against a given regular expression pattern defined as a |
| For matching if in a set of values, each element must be separated by comma. If you want to include an empty value, then it must be defined using double comma, eg ',,bronze,silver,gold', which |
| For matching if not in a set of values, each element must be separated by comma. If you want to include an empty value, then it must be defined using double comma. Example: |
| For matching if the left hand side type is an |
| For matching if the left hand side type is not an |
| For matching if the left hand side is within a range of values defined as numbers: From Camel 2.9: the range values must be enclosed in single quotes. |
| For matching if the left hand side is not within a range of values defined as numbers: From Camel 2.9: the range values must be enclosed in single quotes. |
| Camel 2.17.1, 2.18: For testing if the left hand side string starts with the right hand string. |
| Camel 2.17.1, 2.18: For testing if the left hand side string ends with the right hand string. |
And the following unary operators can be used:
Operator | Description |
---|---|
| Camel 2.9: To increment a number by one. The left hand side must be a function, otherwise parsed as literal. |
| Camel 2.9: To decrement a number by one. The left hand side must be a function, otherwise parsed as literal. |
| Camel 2.9.3 to 2.10.x To escape a value, e.g., Note: Escaping is not supported using the File Language. Note: from Camel 2.11, the escape character is no longer supported. It has been replaced with the following three escape sequences. |
| Camel 2.11: To use newline character. |
| Camel 2.11: To use tab character. |
| Camel 2.11: To use carriage return character. |
| Camel 2.18: To use the |
And the following logical operators can be used to group expressions:
Operator | Description |
---|---|
| Deprecated: use |
| Deprecated: use |
| Camel 2.9: The logical and operator is used to group two expressions. |
| Camel 2.9: The logical or operator is used to group two expressions. |
...
In Camel 2.4 and older the and
or or
can only be used once in a simple language expression.
From Camel 2.5: you can use these operators multiple times.
The syntax for AND
is:
...
And the syntax for OR
is:
...
Some examples:
...
When you compare with different types such as String
and int
, then you have to take a bit care. Camel will use the type from the left hand side as first priority. And fallback to the right hand side type if both values couldn't be compared based on that type. This means you can flip the values to enforce a specific type. Suppose the bar value above is a String
. Then you can flip the equation:
...
which then ensures the int
type is used as first priority.
This may change in the future if the Camel team improves the binary comparison operations to prefer numeric types over String
based. It's most often the String
type which causes problem when comparing with numbers.
...
And a bit more advanced example where the right value is another expression,
...
And an example with contains, testing if the title contains the word Camel:
...
And an example with regex, testing if the number header is a four digit value:
...
And finally an example if the header equals any of the values in the list. Each element must be separated by comma, and no space around. This also works for numbers etc, as Camel will convert each element into the type of the left hand side.
...
And for all the last three we also support the negate test using not
:
...
And you can test if the type is a certain instance, e.g., for instance a String
:
...
We have added a shorthand for all java.lang
types so you can write it as:
...
Ranges are also supported. The range interval requires numbers and both from and end are inclusive. For instance to test whether a value is between 100
and 199
:
...
Notice we use ..
in the range without spaces. It is based on the same syntax as Groovy.
From Camel 2.9: the range value must be in single quotes:
...
As the Spring XML does not have all the power as the Java DSL with all its various builder methods, you have to resort to use some other languages for testing with simple operators. Now you can do this with the simple language. In the sample below we want to test if the header is a widget order:
...
Using and
/ or
If you have two expressions you can combine them with the and
or or
operator.
...
Use &&
or ||
For instance:
...
And of course the or
is also supported. The sample would be:
...
Note: currently and
or or
can only be used once in a simple language expression. This might change in the future. So you cannot do:
...
Samples
In the Spring XML sample below we filter based on a header value:
...
The Simple language can be used for the predicate test above in the Message Filter pattern, where we test if the in message has a foo
header (a header with the key foo
exists). If the expression evaluates to true
then the message is routed to the mock:fooOrders
endpoint, otherwise it is lost in the deep blue sea .
The same example in Java DSL:
...
You can also use the simple language for simple text concatenations such as:
...
Notice that we must use ${}
placeholders in the expression now to allow Camel to parse it correctly.
And this sample uses the date command to output current date.
...
And in the sample below we invoke the bean language to invoke a method on a bean to be included in the returned string:
...
Where orderIdGenerator
is the id of the bean registered in the Registry. If using Spring then it is the Spring bean id.
If we want to declare which method to invoke on the order id generator bean we must prepend .method name
such as below where we invoke the generateId
method.
...
We can use the ?method=methodname
option that we are familiar with the Bean component itself:
...
From Camel 2.3: you can also convert the body to a given type, for example to ensure that it is a String
you can do:
...
There are a few types which have a shorthand notation, so we can use String
instead of java.lang.String
. These are: byte[]
, String
, Integer
, Long
. All other types must use their FQN name, e.g. org.w3c.dom.Document
.
It is also possible to lookup a value from a header Map
in Camel 2.3:
...
In the code above we lookup the header with name type
and regard it as a java.util.Map
and we then lookup with the key gold
and return the value. If the header is not convertible to Map an exception is thrown. If the header with name type
does not exist null
is returned.
From Camel 2.9: you can nest functions, such as shown below:
...
Referring to Constants or Enums
Available from Camel 2.11
Suppose you have an enum for customers:
Using New Lines or Tabs in XML DSLs
Available from Camel 2.9.3
From Camel 2.9.3: it is easier to specify new lines or tabs in XML DSLs as you can escape the value now
...
Leading and Trailing Whitespace Handling
Available from Camel 2.10.0
From Camel 2.10.0: the trim
attribute of the expression can be used to control whether the leading and trailing whitespace characters are removed or preserved. The default of trim=true
removes all whitespace characters.
...
Setting the Result Type
Available from Camel 2.8
You can now provide a result type to the Simple expression, which means the result of the evaluation will be converted to the desired type. This is most usable to define types such as boolean
's, integer
's, etc.
For example to set a header as a boolean
type you can do:
...
And in XML DSL
...
Changing Function Start and End Tokens
Available from Camel 2.9.1
You can configure the function start and end tokens - ${}
using the setters changeFunctionStartToken
and changeFunctionEndToken
on SimpleLanguage
, using Java code. From Spring XML you can define a <bean>
tag with the new changed tokens in the properties as shown below:
...
In the example above we use []
as the changed tokens. Notice by changing the start/end token you change those in all the Camel applications which share the same camel-core
on their classpath. For example in an OSGi server this may affect many applications, where as a Web Application as a WAR file it only affects the Web Application.
Loading Script from External Resource
Available from Camel 2.11
You can externalize the script and have Camel load it from a resource such as: classpath:
, file:
, or http:
. This is done using the following syntax: resource:scheme:location
, e.g., to refer to a file on the classpath you can do:
...
Setting Spring beans to Exchange properties
Available from Camel 2.6
You can set a spring bean into an exchange property as shown below:
...
Dependencies
The Simple
...
<from uri="seda:orders">
<filter>
<simple>in.header.foo</simple>
<to uri="mock:fooOrders"/>
</filter>
</from>
The Simple language can be used for the predicate test above in the Message Filter pattern, where we test if the in message has a foo
header (a header with the key foo
exists). If the expression evaluates to true then the message is routed to the mock:foo
endpoint, otherwise its lost in the deep blue sea .
The same example in Java DSL:
...
from("seda:orders")
.filter().simple("in.header.foo").to("seda:fooOrders");
You can also use the simple language for simple text concatenations such as:
...
from("direct:hello").transform().simple("Hello ${in.header.user} how are you?").to("mock:reply");
Notice that we must use ${ } placeholders in the expression now to let Camel be able to parse it correctly.
And this sample uses the date command to output current date.
...
from("direct:hello").transform().simple("The today is ${date:now:yyyyMMdd} and its a great day.").to("mock:reply");
And in the sample below we invoke the bean language to invoke a method on a bean to be included in the returned string:
...
from("direct:order").transform().simple("OrderId: ${bean:orderIdGenerator}").to("mock:reply");
Where orderIdGenerator
is the id of the bean registered in the Registry. If using Spring then its the Spring bean id.
If we want to declare which method to invoke on the order id generator bean we must prepend .method name
such as below where we invoke the generateId
method.
...
from("direct:order").transform().simple("OrderId: ${bean:orderIdGenerator.generateId}").to("mock:reply");
And in Camel 2.0 we can use the ?method=methodname
option that we are familiar with the Bean component itself:
...
from("direct:order").transform().simple("OrderId: ${bean:orderIdGenerator?method=generateId}").to("mock:reply");
And from Camel 2.3 onwards you can also convert the body to a given type, for example to ensure its a String you can do:
...
<transform>
<simple>Hello ${bodyAs(String)} how are you?</simple>
</transform>
There is a few types which have a shorthand notation, hence why we can use String
instead of java.lang.String
. These are: byte[], String, Integer, Long
. All other types must use their FQN name, e.g. org.w3c.dom.Document
.
Its also possible to lookup a value from a header Map
in Camel 2.3 onwards:
...
<transform>
<simple>The gold value is ${header.type[gold]}</simple>
</transform>
In the code above we lookup the header with name type
and regard it as a java.util.Map
and we then lookup with the key gold
and return the value.
If the header is not convertible to Map an exception is thrown. If the header with name type
does not exists null
is returned.
Dependencies
The Bean language is part of camel-core
.