YAML DSL

Since Camel 3.9

The YAML DSL provides the capability to define your Camel routes, route templates & REST DSL configuration in YAML.

Defining a route

A route is collection of elements defined as follows:

- from: (1)
    uri: "direct:start"
    steps: (2)
      - filter:
          expression:
            simple: "${in.header.continue} == true"
          steps: (2)
            - to:
                uri: "log:filtered"
      - to:
          uri: "log:original"

1	route entry point, by default `from` and `rest` are supported
2	processing steps

Each step is represented by a YAML map that has a single entry where the field name is the EIP name

As a general rule, each step provides all the parameters the related definition declares, but there are some minor differences/enhancements:

Output Aware Steps

Some steps such as filter and split have their own pipeline. When an exchange matches the filter expression or for the items generated by the split expression, such a pipeline can be defined by the steps field:
```
filter:
  expression:
    simple: "${in.header.continue} == true"
    steps:
      - to:
          uri: "log:filtered"
```
Expression Aware Steps

Some EIPs such as filter and split support the definition of an expression through the expression field:
Explicit Expression field
```
filter:
  expression:
    simple: "${in.header.continue} == true"
```
To make the DSL less verbose, the expression field can be omitted:
Implicit Expression field
```
filter:
  simple: "${in.header.continue} == true"
```
In general, expression can be defined inline like in the examples above. But in case you need to provide more information, you can 'unroll' the expression definition and configure any single parameter the expression defines.
Full Expression definition
```
filter:
  tokenize:
    token: "<"
    endToken: ">"
```
Data Format Aware Steps

The EIP marshal and unmarshal supports the definition of data formats:
```
marshal:
  json:
    library: Gson
```
In case you want to use the data-format’s default settings, you need to place an empty block as data format parameters, like json: {}

Defining endpoints

To define an endpoint with the YAML dsl you have two options:

Using a classic Camel URI:

- from:
    uri: "timer:tick?period=1s"
    steps:
      - to:
          uri: "telegram:bots?authorizationToken=XXX"

Using URI and parameters:

- from:
    uri: "timer://tick"
    parameters:
      period: "1s"
    steps:
      - to:
          uri: "telegram:bots"
          parameters:
            authorizationToken: "XXX"

Defining beans

In addition to the general support for creating beans provided by Camel Main, the YAML DSL provides a convenient syntax to define and configure them:

- beans:
  - name: beanFromMap  (1)
    type: com.acme.MyBean (2)
    properties: (3)
      foo: bar

1	the name of the bean which will be used to bound the instance to the Camel Registry
2	the full qualified class name of the bean
3	the properties of the bean to be set

The properties of the bean can be defined using either a map or properties style, as shown in the example below:

- beans:
  # map style
  - name: beanFromMap
    type: com.acme.MyBean
    properties:
      field1: 'f1'
      field2: 'f2'
      nested:
        field1: 'nf1'
        field2: 'nf2'
  # properties style
  - name: beanFromProps
    type: com.acme.MyBean
    properties:
      field1: 'f1_p'
      field2: 'f2_p'
      nested.field1: 'nf1_p'
      nested.field2: 'nf2_p'

The beans elements can only be used as the root element

Creating bean using constructors

When beans must be created with constructor arguments, then this is made easier in Camel 4.1 onwards.

For example as shown below:

- beans:
  - name: myBean
    type: com.acme.MyBean
    constructors:
      0: true
      1: "Hello World"

The constructors is index based so the keys must be numbers starting from zero.

You can use both constructors and properties.

Creating beans from factory method

A bean can also be created from a factory method (public static) as shown below:

- beans:
  - name: myBean
    type: com.acme.MyBean
    factoryMethod: createMyBean
    constructors:
      0: true
      1: "Hello World"

When using factoryMethod then the arguments to this method is taken from constructors. So in the example above, this means that class com.acme.MyBean should be as follows:

public class MyBean {

    public static MyBean createMyBean(boolean important, String message) {
        MyBean answer = ...
        // create and configure the bean
        return answer;
    }
}

The factory method must be public static and from the same class as the created class itself.

Creating beans from factory bean

A bean can also be created from a factory bean as shown below:

- beans:
  - name: myBean
    type: com.acme.MyBean
    factoryBean: com.acme.MyHelper
    factoryMethod: createMyBean
    constructors:
      0: true
      1: "Hello World"

factoryBean can also refer to an existing bean by bean id instead of FQN classname.

When using factoryBean and factoryMethod then the arguments to this method is taken from constructors. So in the example above, this means that class com.acme.MyHelper should be as follows:

public class MyHelper {

    public static MyBean createMyBean(boolean important, String message) {
        MyBean answer = ...
        // create and configure the bean
        return answer;
    }
}

The factory method must be public static.

Creating beans from builder classes

A bean can also be created from another builder class as shown below:

- beans:
  - name: myBean
    type: com.acme.MyBean
    builderClass: com.acme.MyBeanBuilder
    builderMethod: createMyBean
    properties:
      id: 123
      name: 'Acme'

The builder class must be public and have a no-arg default constructor.

The builder class is then used to create the actual bean by using fluent builder style configuration. So the properties will be set on the builder class, and the bean is created by invoking the builderMethod at the end. The invocation of this method is done via Java reflection.

Creating beans using script language

For advanced use-cases then Camel allows to inline a script language, such as groovy, java, javascript, etc, to create the bean. This gives flexibility to use a bit of programming to create and configure the bean.

- beans:
  - name: myBean
    type: com.acme.MyBean
    scriptLanguage: groovy
    script: >
      // some groovy script here to create the bean
      bean = ...
      ...
      return bean

When using script then constructors and factory bean/method is not in use

Using init and destroy methods on beans

Sometimes beans need to do some initialization and cleanup work before a bean is ready to be used. For this you can use initMethod and destroyMethod that Camel triggers accordingly.

Those methods must be public void and have no arguments, as shown below:

public class MyBean {

    public void initMe() {
        // do init work here
    }

    public void destroyMe() {
        // do cleanup work here
    }

}

You then have to declare those methods in YAML DSL as follows:

- beans:
  - name: myBean
    type: com.acme.MyBean
    initMethod: initMe
    destroyMethod: destroyMe
    constructors:
      0: true
      1: "Hello World"

The init and destroy methods are optional, so a bean does not have to have both, for example you may only have destroy methods.

Configuring options on languages

Some Languages have additional configurations you may need to use.

For example, the JSONPath can be configured to ignore JSon parsing errors. This is intended when you use a Content Based Router and want to route the message to different endpoints. But the JSon payload of the message can be in different forms; meaning that the JSonPath expressions in some cases would fail with an exception, and other times not. In this situation, you need to set suppress-exception to true, as shown below:

- from:
    uri: "direct:start"
    steps:
      - choice:
          when:
          - jsonpath:
              expression: "person.middlename"
              suppressExceptions: true
            steps:
            - to: "mock:middle"
          - jsonpath:
              expression: "person.lastname"
              suppressExceptions: true
            steps:
            - to: "mock:last"
          otherwise:
            steps:
              - to: "mock:other"

In the route above, the following message

{
  "person": {
    "firstname": "John",
    "lastname": "Doe"
  }
}

Would have failed the JSonPath expression person.middlename because the JSon payload does not have a middlename field. To remedy this we have suppressed the exception.

External examples

You can find a set of examples using main-yaml in Camel Examples which demonstrate creating Camel Routes with YAML.

Another way to find examples of YAML DSL is to look in Camel Kamelets where each Kamelet is defined using YAML.