= Writing Integrations in YAML

== Defining a route

A route is collection of elements defined as follows:

[source,yaml]
----
- 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

[NOTE]
====
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:
+
[source,yaml]
----
filter:
  expression:
    simple: "${in.header.continue} == true"
      steps:
        - to:
            uri: "log:filtered"
----
+
[NOTE]
====
if the `steps` field is omitted, then each subsequent step is considered part of the filter pipeline.
====

- *Expression Aware Steps*
+
Some EIP such as `filter` and `split` supports the definition of an expression through the `expression` field:
+
[source,yaml]
.Explicit Expression field
----
filter:
    expression:
      simple: "${in.header.continue} == true"
----
+
To make the DSL less verbose, the `expression` field can be omitted:
+
[source,yaml]
.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.
+
[source,yaml]
.Full Expression definition
----
filter:
    tokenize:
      token: "<"
      end-token: ">"
----

- *Data Format Aware Steps*
+
Some EIP such as `set-body` and `marshal` supports the definition of data formats through the `data-format` field:
+
[source,yaml]
.Explicit Data Format field
----
set-body:
    data-format:
      json:
        library: Gson
----
+
To make the DSL less verbose, the `data-format` field can be omitted:
+
[source,yaml]
.Implicit Data Format field
----
set-body:
    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: {}`
====

== Defining endpoints

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

. Using a classic Camel URI:
+
[source,yaml]
----
- from:
    uri: "timer:tick?period=1s"
    steps:
      - to:
          uri: "telegram:bots?authorizationToken=XXX"
----
. Using URI and parameters:
+
[source,yaml]
----
- from:
    uri: "timer://tick"
    parameters:
      period: "1s"
    steps:
      - to:
          uri: "telegram:bots"
          parameters:
            authorizationToken: "XXX"
----
. Using the YAML implementation of the xref:manual::Endpoint-dsl.adoc[Endpoint DSL]:
+
[source,yaml]
----
- from:
    timer:
      name: "tick"
      period: "1s"
    steps:
      - telegram:
          type: "bots"
          authorizationToken: "XXX"
----

[WARNING]
====
Support for the Endpoint DSL with YAML is experimental and subject to changes.
====
[NOTE]
====
Support for Endpoint DSL auto completion https://github.com/apache/camel-k-runtime/issues/485[is not yet available].
====

== 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:

[source,yaml]
----
- 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:

[source,yaml]
----
- 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 can only be used as root element
====

== Supported EIP

This is the list of EIPs supported in the yaml DSL language. For full details on expected configuration you can please refer to the https://github.com/apache/camel/blob/main/dsl/camel-yaml-dsl/camel-yaml-dsl/src/generated/resources/schema/camel-yaml-dsl.json[YAML language specification].

- Aggregate
- Bean
- Choice
- Circuit Breaker
- Claim Check
- Convert Body To
- Delay
- Dynamic Router
- Enrich
- Filter
- From
- Idempotent Consumer
- Load Balance
- Log
- Loop
- Marshal
- Multicast
- Pipeline
- PollEnrich
- Process
- Recipient List
- Remove Header
- Remove Headers
- Remove Property
- Remove Properties
- Resequence
- Rest DSL
- Rollback
- Routing Slip
- Saga
- Sample
- Script
- ServiceCall
- Set Body
- Set Exchange Pattern
- Set Header
- Set Property
- Sort
- Split
- Step
- Stop
- Threads
- Throttle
- Throw Exception
- To
- To Dynamic
- Transacted
- Transform
- Try Catch Finally
- Unmarshal
- Validate
- Wire Tap

The Try Catch Finally EIP currently only support specifying one `do-catch` clause.
