[jira] [Updated] (CAMEL-10642) support input/result/path support when invoking a `to` endpoint

["james strachan (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-10642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

james strachan updated CAMEL-10642:
-----------------------------------
    Description: 
there's an interesting concept in AWS Step Functions for input and output processing: https://states-language.net/spec.html#filters

namely that given some raw in, you can specify an `input` expression for filtering the raw input before sending it to an endpoint; then a `result` path expression where the result can be stored in the raw input; then the `output` expression which is used to filter the resulting raw input & output for the next step.

i.e. its a simple way to compose inputs and outputs into a single message using a path expression language (in this case JsonPath).

It might be nice to add the same kind of mechanism to the DSL. e.g. right now we take the output and pass it to the next step in the route. However it might be nice if folks could specify where the output goes in the initial raw input; for example to compose the results from a number of endpoints into a single message.

One issue with the current camel Expression API is there's no concept of storing a result at a `reference path`. 

e.g. if the raw input was
{code:javascript}
{
  "title": "Numbers to add",
  "numbers": { "val1": 3, "val2": 4 }
}
{code}
and we used
{code:javascript}
"InputPath": "$.numbers",
"ResultPath": "$.sum"
{code}
to then invoke an endpoint that sums the numbers, we'd get the result output:
{code:javascript}
{
  "title": "Numbers to add",
  "numbers": { "val1": 3, "val2": 4 },
  "sum": 7
}
{code}

so it may only be a subset of Languages we can support this 'resultPath` behaviour. At least JsonPath supports this at the implementation. So in speudo code its something like {code}jsonpath.set(rawInput, endpointOutput){code} 

So we'd need to add a new interface that an Expression may support; UpdateExpression or something like that, along these lines:

{code:java}
/** takes the value and updates it inside the input exchange payload */
public interface UpdateExpression extends Expression {
   public Object update(Exchange rawInput, Object value, Class clazz);
{code}

In terms of a DSL we may want to have a `ToDefinition` like step which has a language and optional input, result, output expressions. Maybe something like...
{code:java}
from("foo").invoke().jsonPath().input("$").result("$").output("$").to("whatnot")
{code}

I'm not totally sure about the 'invoke' name here but figured we'd need something different from 'to' to differentiate it in the Java DSL? Then `invoke().jsonPath()` would return an InvokeExpression. Then for the 'InvokeDefinition' we'd need to specify a language along with optional expressions (input, output, result) then the "to" would be the last expression so that the DSL returns back to the usual DSL again.

We may want to use the idea of default expressions; so that if nothing is provided then for jsonPath we assume $ so that if you wish to not send any input or output you use an explicit null for those expressions.

  was:
there's an interesting concept in AWS Step Functions for input and output processing: https://states-language.net/spec.html#filters

namely that given some raw in, you can specify an `input` expression for filtering the raw input before sending it to an endpoint; then a `result` path expression where the result can be stored in the raw input; then the `output` expression which is used to filter the resulting raw input & output for the next step.

i.e. its a simple way to compose inputs and outputs into a single message using a path expression language (in this case JsonPath).

It might be nice to add the same kind of mechanism to the DSL. e.g. right now we take the output and pass it to the next step in the route. However it might be nice if folks could specify where the output goes in the initial raw input; for example to compose the results from a number of endpoints into a single message.

One issue with the current camel Expression API is there's no concept of storing a result at a `reference path`. 

e.g. if the raw input was
{code:javascript}
{
  "title": "Numbers to add",
  "numbers": { "val1": 3, "val2": 4 }
}
{code}
and we used
{code:javascript}
"InputPath": "$.numbers",
"ResultPath": "$.sum"
{code}
to then invoke an endpoint that sums the numbers, we'd get the result output:
{code:javascript}
{
  "title": "Numbers to add",
  "numbers": { "val1": 3, "val2": 4 },
  "sum": 7
}
{code}

so it may only be a subset of Languages we can support this 'resultPath` behaviour. At least JsonPath supports this at the implementation. So in speudo code its something like {code}jsonpath.set(rawInput, endpointOutput){code} 


In terms of a DSL we may want to have a `ToDefinition` like step which has a language and optional input, result, output expressions. Maybe somethign like...
{code:java}
from("foo").invoke().jsonPath().input("$").result("$").output("$").to("whatnot")
{code}

I'm not totally sure about the 'invoke' name here but figured we'd need something different from 'to' to differentiate it in the Java DSL? Then `invoke().jsonPath()` would return an InvokeExpression. Then for the 'InvokeDefinition' we'd need to specify a language along with optional expressions (input, output, result) then the "to" would be the last expression so that the DSL returns back to the usual DSL again.

We may want to use the idea of default expressions; so that if nothing is provided then for jsonPath we assume $ so that if you wish to not send any input or output you use an explicit null for those expressions.


> support input/result/path support when invoking a `to` endpoint
> ---------------------------------------------------------------
>
>                 Key: CAMEL-10642
>                 URL: https://issues.apache.org/jira/browse/CAMEL-10642
>             Project: Camel
>          Issue Type: Improvement
>            Reporter: james strachan
>
> there's an interesting concept in AWS Step Functions for input and output processing: https://states-language.net/spec.html#filters
> namely that given some raw in, you can specify an `input` expression for filtering the raw input before sending it to an endpoint; then a `result` path expression where the result can be stored in the raw input; then the `output` expression which is used to filter the resulting raw input & output for the next step.
> i.e. its a simple way to compose inputs and outputs into a single message using a path expression language (in this case JsonPath).
> It might be nice to add the same kind of mechanism to the DSL. e.g. right now we take the output and pass it to the next step in the route. However it might be nice if folks could specify where the output goes in the initial raw input; for example to compose the results from a number of endpoints into a single message.
> One issue with the current camel Expression API is there's no concept of storing a result at a `reference path`. 
> e.g. if the raw input was
> {code:javascript}
> {
>   "title": "Numbers to add",
>   "numbers": { "val1": 3, "val2": 4 }
> }
> {code}
> and we used
> {code:javascript}
> "InputPath": "$.numbers",
> "ResultPath": "$.sum"
> {code}
> to then invoke an endpoint that sums the numbers, we'd get the result output:
> {code:javascript}
> {
>   "title": "Numbers to add",
>   "numbers": { "val1": 3, "val2": 4 },
>   "sum": 7
> }
> {code}
> so it may only be a subset of Languages we can support this 'resultPath` behaviour. At least JsonPath supports this at the implementation. So in speudo code its something like {code}jsonpath.set(rawInput, endpointOutput){code} 
> So we'd need to add a new interface that an Expression may support; UpdateExpression or something like that, along these lines:
> {code:java}
> /** takes the value and updates it inside the input exchange payload */
> public interface UpdateExpression extends Expression {
>    public Object update(Exchange rawInput, Object value, Class clazz);
> {code}
> In terms of a DSL we may want to have a `ToDefinition` like step which has a language and optional input, result, output expressions. Maybe something like...
> {code:java}
> from("foo").invoke().jsonPath().input("$").result("$").output("$").to("whatnot")
> {code}
> I'm not totally sure about the 'invoke' name here but figured we'd need something different from 'to' to differentiate it in the Java DSL? Then `invoke().jsonPath()` would return an InvokeExpression. Then for the 'InvokeDefinition' we'd need to specify a language along with optional expressions (input, output, result) then the "to" would be the last expression so that the DSL returns back to the usual DSL again.
> We may want to use the idea of default expressions; so that if nothing is provided then for jsonPath we assume $ so that if you wish to not send any input or output you use an explicit null for those expressions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)