On Sun, Sep 16, 2012 at 7:32 PM, Raul Kripalani <r...@evosent.com> wrote:
> Hi guys,
>
> A fair number of users rely on Camel for business orchestration, with
> varying degrees of complexity.
>
> One shortcoming of Camel compared to BPEL is that you can't embed
> assignment and field-focused transformation rules, like you can do with the
> BPEL Assign activity. With XML payloads, I would love to copy, transfer,
> transform values from a source to an origin, without having to write an
> external resource (XSLT, XQuery, Velocity template, etc.). Take a look at
> the data manipulation features in BPEL [1].
>
> What do you think?
>
There is EIPs for setting headers/body/property on the
Message/Exchange. So you can assign these 3 currently.
And for other stuff you can just use a 3rd party language such as
Groovy etc. There you can do whatever you want.
Though usually a language is used as part of a an expression/predicate
in Camel. What may be missing
is to execute a script. So in that script you can do any kind of
assignments and whatnot. And the script
can be embedded in the DSL
from X
script.groovy {
header.foo = 4 + 7 + header.bar
header.bar = header.bar + 1
}
to bla
We already have the language component that can execute the script
http://camel.apache.org/language.html
What is missing though is a DSL that can execute it without taking any
response and setting as a new header / body etc. eg currently we have
the transform / setHeader / setBody etc in the DSL. What we would need
is a new DSL for "script"
So IMHO this could be a good addition, to have that script, then
people can do whatever they want in there.
> Also, something that's missing is running transformation scripts contained
> in files. Right now, we can only embed Groovy, JS, JRuby, etc. scripts
> inside Expressions or Predicates. I'd love to be able to create an endpoint
> like: "groovy:file:/opt/resources/transformMessage.groovy", and have Camel
> take care of the appropriate variable bindings to make the Exchange,
> Headers, Properties, Context, etc. available to the script.
>
> Does anyone have experience with Spring's support for Dynamic Languages in
> this context? [2]. Maybe having Spring take care of plugging in the script
> so that it's referenceable as a normal bean?
>
> Regards,
> Raúl.
>
> ---
> *Raúl Kripalani *
> Enterprise Architect, Program Manager, Open Source Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> [1] http://docs.oracle.com/cd/E11036_01/integrate.1013/b28981/manipdoc.htm
> [2]
> http://static.springsource.org/spring/docs/3.0.x/reference/dynamic-language.html
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
