ReggieCarey commented on issue #673:
URL: https://github.com/apache/camel-kamelets/issues/673#issuecomment-1007527212
@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}".
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?
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)?
```
- 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?
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?
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.
--
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: commits-unsubscr...@camel.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
