[
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/29/23 11:44 AM:
----------------------------------------------------------------
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} *DONE*
- 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
*DONE*
- log EIP and component *DONE*
- tracing
- debugging
- camel-jbang
- documentation
- example
- SPI for flexibility in the future (store, scope)
- experimental DSLs such as groovy, kotlin, js *NO NEED*
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 *DONE*
- expression builder *DONE*
- Simple language ${variable.xxx} ${variables} *DONE*
- 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
*DONE*
- log EIP and component *DONE*
- 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)
