oscerd commented on issue #673:
URL: https://github.com/apache/camel-kamelets/issues/673#issuecomment-1008015965
> @oscerd Thanks for all of the effort, I think this mod adds a huge amount
of capability.
>
> But lots of questions and some suggestions:
>
> I'm curious about what it implies to use "Simple" and not Constant for the
value parameter binding. This would be very handy in the docs. At a high level,
I think it allows for strings with embedded expansions "${some_variable}" but
that's just an assumption on my part. Could you add into the documentation what
variables we have access to in this expansion and their types (Map, Array,
Object, etc.) , e.g. `header` as in "${header[ce-source]}",
"${header.ce-source}".
>
You could have an idea of how simple works and what is supported from here:
https://camel.apache.org/components/3.14.x/languages/simple-language.html
I can add a link in the description about simple language and maybe add some
examples somewhere. Yeah.
> I see a potential problem down the road with using a single fixed header
(CamelKameletsExtractFieldName). What happens when I need to extract more than
one thing to be placed in the header?
>
For the header name it makes sense, need to think about a possibile good way
of sanitizing. I'd probably also make the sanitize logic optional, like having
headerExistenceCheck true or false. Not sure.
I think you're meaning to concatenate more extract-field-action steps and
then concatenate the headers when you've done in a new header to use down the
route. In that case, yes, it's not a good design what I've done, because you'll
end up to have the same header overriden. Ok, I'll check this scenario too.
> Could you do something like this? Note the "field" as well as alternate
use of "headerOutput". If we know the payload is JSON, then "field" needs to be
interpreted to identify any entry in that json. Ideally this would use a common
syntax such as that used by [JQ](https://stedolan.github.io/jq/)
>
> B.T.W. what happens if the thing requested in "field" is not a simple type
(string, boolean, number)?
Well, if you have something like a complex type, what you'll get will always
be a JSON (just a subset of the original one), with that, you could for example
use deserialize-action and transform the JSON into a POJO instance. But in the
original design, what is going through actions is always a JSON. By the way
maybe adding some examples will be better.
>
> ```
> - route:
> from:
> uri: "kamelet:kafka-source"
> ...
> steps:
> - to:
> uri: "kamelet:extract-field-action"
> parameters:
> field: "endUser[3].familyName"
> headerOutput: "FAMILY_NAME"
> - to:
> uri: "kamelet:extract-field-action"
> parameters:
> field: "endUser[3].givenName"
> headerOutput: "GIVEN_NAME"
> - to:
> uri: "kamelet:insert-header-action"
> parameters:
> name: "ce-indexId"
> value: "${header.FAMILY_NAME}_${header.GIVEN_NAME}"
> or
> value: "${header[FAMILY_NAME]}_${header[GIVEN_NAME]}"
> - to:
> uri: "kamelet:elasticsearch-index-sink"
> ...
> ```
>
> If my understanding of "Simple" is correct, then in a **KameletBinding**
one could establish the headerOutputs in steps A and B and then combine the
headers in a subsequent step C as per `value:
"${header.FAMILY_NAME}_${header.GIVEN_NAME}"`. Am I understanding the intent
properly?
Yes, you could do something like that, but first we need to sanitize the
headerName in some way.
>
> Does the Camel DSL or some subset extend to KameletBindings or is it
limited to Kamelets? How much room for configuration do people have if all they
want to do is blend existing Kamelets into a solution?
>
In the beginning Kamelet were only part of camel-k, so you could use the
kameletBinding as part of a camel-k integration.
Later we started to support Kamelet as a plain Camel component and you could
do something like from(kamelet:aws-s3).to(kamelet:kafka-sink) even outside
camel-k and cloud.
Later we added the support of kamelet into a Jbang extension, still
experimental.
So you can use both camel-k, through KameletBinding yaml or you can use
camel-kamelet-main through a Camel yaml route using the camel-kamelet component
or you could even use the camel-jbang extension for a fast feedback about the
yaml route based on kamelets from catalog you're using. But this needs to be
defined in the documentation of catalog, camel-kamelets, camel-kamelet-main and
camel-jbang a bit better.
> SPECULATION: I see a need for a generic CloudEvent payload processor
Action at some point in the future that gives the ability to read and
manipulate any payload not just ones that are JSON encoded. Maybe it is limited
to payloads defined with a json schema or protocol buffer or some such to make
accessing the contents more predictable. It might involve introducing a block
of user defined code (groovy or python script block?) added to the
kameletbinding yaml that executes in some sort of sandbox.
There were an issue in Camel JIRA about a camel-cloudevent compoonent. But I
don't remember if we had some developments around this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
