YAML DSL

Since Camel 3.9

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 general rule each step provide 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 pipeline can be defined by the steps field:

    filter:
      expression:
        simple: "${in.header.continue} == true"
        steps:
          - to:
              uri: "log:filtered"
  • Expression Aware Steps

    Some EIP such as filter and split supports 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 provide more information, you can 'unroll' the expression definition and configure any single parameter the expression defines.

    Full Expression definition
    filter:
      tokenize:
        token: "<"
        end-token: ">"
  • 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 three options:

  1. Using a classic Camel URI:

    - from:
        uri: "timer:tick?period=1s"
        steps:
          - to:
              uri: "telegram:bots?authorizationToken=XXX"
  2. 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 provide 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 root element

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 exceptions, and other times not. In this situation you need to set suppress-exception to true, as shown belo:

- from:
    uri: "direct:start"
    steps:
      - choice:
          when:
          - jsonpath:
              expression: "person.middlename"
              suppress-exceptions: true
            steps:
            - to: "mock:middle"
          - jsonpath:
              expression: "person.lastname"
              suppress-exceptions: 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.

Camel K support

The camel-yaml-dsl is supported by Camel K.

Loading Camel K integrations

A Camel K integration (in CRD format (Custom Resource Definition in Kubernetes)) can be loaded by camel-yaml-dsl and run as routes:

apiVersion: camel.apache.org/v1
kind: Integration
metadata:
  name: hello.yaml
spec:
  flows:
    - from:
        uri: "timer:tick?period=5000"
      steps:
        - to: "log:tick"

Loading Camel K bindings

A Camel K binding (in CRD format; Custom Resource Definition in Kubernetes) can be loaded by camel-yaml-dsl and run as routes:

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: joke
spec:
  source:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1
      name: chuck-norris-source
    properties:
      period: 2000
  sink:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1
      name: log-sink
    properties:
      show-headers: false