Following up on this. I managed to stand up a route from within a kamelet thanks to a custom route policy and a Camel context startup listener. Might need to tweak/revise my approach because of some kamelet limitations but I don't think they're blockers. Thanks for the help.
Claude On Mon, Jul 22, 2024 at 9:14 AM Claude Mamo <claude.m...@gmail.com> wrote: > 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 >> > > > >> > > >> > >> >
