chore: Add data-type-action Kamelet

[christophd]

• Adds new action Kamelet to leverage Kamelet input/ouput data types
• Enables users to apply data type conversion as part of a KameletBinding
• Introduces new data type implementation representing the CloudEvents Http binding
• Add some YAKS tests to verify data-type-action Kamelet
• Use Kamelets from local directory when running YAKS tests in GitHub workflow

[christophd]

Let me explain a bit on these changes. With the new data-type action Kamelet users are able to explicitly apply a given data type conversion in a Kamelet Binding:

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: data-type-action-binding
spec:
  source:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: timer-source
    properties:
      period: 5000
      contentType: application/json
      message: >
        ${input}
  steps:
    - ref:
        kind: Kamelet
        apiVersion: camel.apache.org/v1alpha1
        name: data-type-action
      properties:
        scheme: "http"
        format: "cloudevents"
  sink:
    uri: http://test-service/result

Here for example the data type applies the Http CloudEvents binding on a timer-source event. The data type is able to work with Camel specific CloudEvent headers and also sets some CloudEvents defaults. The resulting Http request looks like this (with proper CloudEvents headers set):

POST /someresource HTTP/1.1
Host: webhook.example.com
ce-specversion: 1.0
ce-type: org.apache.camel.event
ce-time: {{exchange-timestamp}}
ce-id: {(exchange-id})
ce-source: org.apache.camel
Content-Type: application/json; charset=utf-8
Content-Length: xxx

{
    ... application data ...
}

The combination with other data types (e.g. AWS-S3 Cloudevents data tpye) creates proper CloudEvent data from AWS-S3 to Http for example where the AWS-S3 data type creates proper Camel CloudEvents headers on the exchange and the Http CloudEvents data type translates these to proper Http headers.

apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: aws-s3-to-http
spec:
  source:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: aws-s3-source
    properties:
      bucketNameOrArn: someBucket
      [...]
  steps:
    - ref:
        kind: Kamelet
        apiVersion: camel.apache.org/v1alpha1
        name: data-type-action
      properties:
        scheme: "aws2-s3"
        format: "cloudevents"
    - ref:
        kind: Kamelet
        apiVersion: camel.apache.org/v1alpha1
        name: data-type-action
      properties:
        scheme: "http"
        format: "cloudevents"
  sink:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: http-sink
    properties:
      url: http:://test-service/incoming

[oscerd]

This is really important: we could avoid modifying the current kamelets code and leave the choice oto the user to use or not use the action.
I think the next step should be removing the experimental kamelets then.

After that we should see if we might need to create more beans for all the supported kamelets to use in this action. But I need to dig a bit more

Does this sounds correct to you?

[christophd]

@oscerd Yes, sounds good, many thanks. I will prepare a PR to remove the experimental Kamelets as a next step

[christophd]

still not sure about the name 'data-type-action' though. Something like 'apply-data-type-action' would be a bit long. any ideas?

[oscerd]

still not sure about the name 'data-type-action' though. Something like 'apply-data-type-action' would be a bit long. any ideas?

maybe data-type-transform-action?