[ 
https://issues.apache.org/jira/browse/CAMEL-19749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17800947#comment-17800947
 ] 

Claus Ibsen edited comment on CAMEL-19749 at 12/28/23 12:20 PM:
----------------------------------------------------------------

We should have a basic implementation first:

- scoped to exchange lifecycle (aka request scope) *DONE*
- api on exchange *DONE*
- in-memory only *DONE*
- DSL setVariable *DONE*
- DSL removeVariable *DONE*
- mock component *DONE*
- @Variable for bean parameter binding *DONE*
- expression builder *DONE*
- Simple language ${variable.xxx} ${variables}
- common EIPs and data formats that return result to message body should allow 
to store result to var instead
- templated components (velocity, freemarker, etc) to have access to variables
- log EIP and component
- tracing
- debugging
- camel-jbang
- documentation
- example
- SPI for flexibility in the future (store, scope)
- experimental DSLs such as groovy, kotlin, js

Should we use short name "var" or use long "variable" instead. Lets use long 
name to not confuse or clash with Java "var"




was (Author: davsclaus):
We should have a basic implementation first:

- scoped to exchange lifecycle (aka request scope) *DONE*
- api on exchange *DONE*
- in-memory only *DONE*
- DSL setVariable *DONE*
- DSL removeVariable *DONE*
- mock component *DONE*
- @Variable for bean parameter binding
- expression builder
- Simple language ${variable.xxx} ${variables}
- common EIPs and data formats that return result to message body should allow 
to store result to var instead
- templated components (velocity, freemarker, etc) to have access to variables
- log EIP and component
- tracing
- debugging
- camel-jbang
- documentation
- example
- SPI for flexibility in the future (store, scope)
- experimental DSLs such as groovy, kotlin, js

Should we use short name "var" or use long "variable" instead. Lets use long 
name to not confuse or clash with Java "var"



> camel-core - Allow users to use variables in route to store data instead of 
> headers
> -----------------------------------------------------------------------------------
>
>                 Key: CAMEL-19749
>                 URL: https://issues.apache.org/jira/browse/CAMEL-19749
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-core, eip
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>            Priority: Major
>             Fix For: 4.4.0
>
>
> Users that need to do message transformation in Camel routes may find 
> themselves having to store data in headers / claim-check / exchange 
> properties from multiple sources before they have all data needed to build a 
> response message.
> Today users are doing this in different ways.
> However we may want to introduce variables that users can name and store the 
> data, then they can do this more intuitive, like they would do in a 
> programming language.
> {code}
> from(kafka("topic1").setVar("customer"))
>    .to("sql:get-order-by-cust?id=${var.customer.id}").setVar("order")
>     .transform().simple( ' Thank you ${var.customer.name} for ordering 
> ${var.order.item}'))
> {code}
> Then you have 2 variables
> - customer
> - order
> Then the variable customer can be used anywhere in Camel like it was a header 
> with ${header.xxx} but with ${var.customer} in the simple language etc.
> This proposal needs some more though and design/prototype.
> But this should be done in a way that does not affect regular Camel DSL as it 
> is, but with variables then results during routing that usually will be 
> override current message body / headers, are stored in variables, that the 
> user assign a name and therefore better can understand what the data the 
> variable contains are.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to