Thanks Murat and Ivan for your input. Kamelets might do the trick for some scenarios we have in mind. I'm not sure if we can hide the complexity behind Kamelets for this scenario where we want to overlay from/to endpoints (e.g., http) with the ability to store and replay messages which is a common requirement when integrating health systems. As I see it, this is not just a matter of persisting the message but also transparently injecting an intermediate route to consume the message and replay it. From the little prototyping I've done till now, it doesn't seem I can have multiple routes in a Kamelet.
On Sat, Jul 20, 2024 at 8:54 PM Marat Gubaidullin < marat.gubaidul...@gmail.com> wrote: > Hello Claude. > > To make it intuitive in Karavan you could make your custom Kamelets that > incapsulate components/dsl configuration complexity. > > On Sat, Jul 20, 2024, 12:28 Claude Mamo <claude.m...@gmail.com> wrote: > > > 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 > > > > > > > > > >
