Chapter 147. YAML DSL Since Camel 3.9 The YAML DSL provides the capability to define your Camel routes, route templates & REST DSL configuration in YAML. 147.1. Defining a route A route is a collection of elements defined as follows: - from: 1 uri: "direct:start" steps: 2 - filter: expression: simple: "USD{in.header.continue} == true" steps: - to: uri: "log:filtered" - to: uri: "log:original" Where, 1 Route entry point, by default from and rest are supported. 2 Processing steps Note Each step represents 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. You can define these pipelines in the steps field: filter: expression: simple: "USD{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: "USD{in.header.continue} == true" To make the DSL less verbose, you can omit the expression field. Implicit Expression field filter: simple: "USD{in.header.continue} == true" In general, expressions can be defined inline, such as within the examples above but if 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 Note 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: {} 147.2. 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" 147.3. 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 Where, 1 The name of the bean which will 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' Note The beans elements is only used as root element. 147.4. Configuring Options Camel components are configured on two levels: Component level Endpoint level 147.4.1. Component Level Options The component level is the highest level. The configurations you define at this level are inherited by all the endpoints. For example, a component can have security settings, credentials for authentication, urls for network connection, and so on. Since components typically have pre-configured defaults for the most common cases, you may need to only configure a few component options, or maybe none at all. You can configure components with Component DSL in a configuration file (application.properties|yaml), or directly with Java code. 147.4.2. Endpoint Level Options At the Endpoint level you have many options, which you can use to configure what you want the endpoint to do. The options are categorized according to whether the endpoint is used as a consumer (from) or as a producer (to) or used for both. You can configure endpoints directly in the endpoint URI as path and query parameters. You can also use Endpoint DSL and DataFormat DSL as type safe ways of configuring endpoints and data formats in Java. When configuring options, use Property Placeholders for urls, port numbers, sensitive information, and other settings. Placeholders allows you to externalize the configuration from your code, giving you more flexible and reusable code. 147.5. Configuring Options on languages Some languages have additional configurations that 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. 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 must set suppress-exception to true, as shown below: - 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 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. { "person": { "firstname": "John", "lastname": "Doe" } } 147.6. External examples You can find a set of examples using main-yaml in Camel examples that demonstrate how to create the Camel Routes with YAML. You can also refer to Camel Kamelets where each Kamelet is defined using YAML.

Commands:
- from: 1 uri: "direct:start" steps: 2 - filter: expression: simple: "USD{in.header.continue} == true" steps: - to: uri: "log:filtered" - to: uri: "log:original"
filter: expression: simple: "USD{in.header.continue} == true" steps: - to: uri: "log:filtered"
filter: expression: simple: "USD{in.header.continue} == true"
filter: simple: "USD{in.header.continue} == true"
filter: tokenize: token: "<" end-token: ">"
marshal: json: library: Gson
- from: uri: "timer:tick?period=1s" steps: - to: uri: "telegram:bots?authorizationToken=XXX"
- from: uri: "timer://tick" parameters: period: "1s" steps: - to: uri: "telegram:bots" parameters: authorizationToken: "XXX"
- beans: - name: beanFromMap 1 type: com.acme.MyBean 2 properties: 3 foo: bar
- 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'
- 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"
{ "person": { "firstname": "John", "lastname": "Doe" } }