camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "james strachan (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-10642) support input/result/path support when invoking a `to` endpoint
Date Thu, 22 Dec 2016 12:04:58 GMT

     [ 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}

Which for now we'd only implement with JsonPath but could support other languages over time
(e.g. XPath should be fine too)

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} 

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.


> 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}
> Which for now we'd only implement with JsonPath but could support other languages over
time (e.g. XPath should be fine too)
> 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)

Mime
View raw message