Yeah I had considered it but the functionality we want to provide would be more intuitive if it's part of the DSL. On the minus side, providing a custom DSL would make it harder for us to integrate with designers like Apache Karavan so that's for sure something we need to factor in. I should highlight that the fromHie(...) EIP example is actually meant to be a wrapper for any endpoint (direct, http, etc...). I could use interceptors, however, I'm trying to make this more idiomatic.
On Sat, Jul 20, 2024 at 1:55 PM Ivan Kulaga <kulagaivanandreev...@gmail.com> wrote: > Hello Claude! > > Please tell, have you considered writing custom components? Writing a new > component is a somewhat common task, and there are many instruments and > examples for that in camel ( > https://camel.apache.org/manual/writing-components.html). > With custom components, your camel route may look like this: > from("hie:my-hie-server-address?my-hie-parameter=value") > .transform(...) > .to(mrs:my-mrs-server-address?action=open) > .transform(...) > .to("hie:my-hie-server-address") > Writing custom components does not require forking camel repo, you can just > add them as a dependency in your application and then add them to camel > context at application configuration step. > > Best regards, > > Ivan > > On Sat, Jul 20, 2024 at 4:23 PM Claude Mamo <claude.m...@gmail.com> wrote: > > > Hello Camel community, > > > > Probably this has been asked before but couldn't find a good answer in > the > > mailing lists nor Zulip. I'd like to tailor the Camel Java DSL for health > > information exchange. This means creating a no. of EIPs. For example: > > > > fromHie(...).transform(...).openMRS(...).transform(...).toHie(...) > > > > So far, all I've come up with is a base class extending RouteBuilder but > > this approach doesn't really work for various reasons. I've came across > > https://github.com/oehf/ipf/tree/master which I think it's extending the > > Camel DSL by means of Groovy metaprogramming. Doesn't seem like a bad > > approach though I'm looking for alternatives which don't include forking > > the Camel repo. Ideas? As a side note, I'd also like to extend the YAML > DSL > > but my focus is on the Java one for now. > > > > Cheers, > > > > Claude > > >
