Add support for property mapping in Kamelets

[nicolaferraro]

How to deal with components that don't support setting up data (e.g. credentials) in the endpoint URI (e.g. Salesforce)?

Currently a Kamelet can define a flow, but maybe we can let the kamelet define properties in order to deal with these cases.
E.g. the Salesforce kamelet can setup the component properties this way, i.e. by interpolating kamelet properties.

They'll be global, but this is sufficient for the source/sink use case.
Wdyt @lburgazzoli, @davsclaus ?

[lburgazzoli]

IMHO we should fix the component and about the salesforce one, it is being worked by @dhirajsb

The global approach would work for sources and sinks but not for general purpose kamelets as - I don't know how common it is - that approach would fail in a salesforce-to-salesforce use case.

[oscerd]

We need to go through the camel components and fix all the situation like the Salesforce one

[davsclaus]

Actually I dont think we can make components to be 100% configurable on endpoint levels. For example JMS you need to setup a connection factory and some other bits which is component level.

I would say kamelets should allow to configure global settings like credentials on a higher level that then become component level configurations, or even something that can configure camel-main/camel-quarkus etc.

eg basically what you can configure with

camel.component.salesforce.xxx = 123

should be something we think into the kamelet concept.

[lburgazzoli]

But that would break if you do as example slaesforce-to-salesforce with different credentials

[davsclaus]

When you start to mess with this like on salesforce then it become more complex to allow to configure on endpoint level and component level. And frankly endpoint level can sometimes become too complex with long uris with many options. And you need to repeat yourself when you use the same component in more endpoints.

[davsclaus]

You would setup a 2nd component as salesforce2.

what dhiraj would be doing is wrong and would make things complex/worse. You have always had to create a 2nd component, eg jms has the same.

[lburgazzoli]

I guess we should not remove the option to configure at component level but also to provide option to configure things on endpoint level, at the end the goal of a template/kamelet is exactly to hide the complexity.

If we don't want to add such option to the endpoint, that would mean that each template should create its own copy of every component that may be used behind the scenes right ? So if we want to go to that path, we need to provide such support in the template concept.

[davsclaus]

Yes in theory and no in practice.

Some components that may be internal like seda rely on being a singleton component as it holds the queues etc. So there is no clear line.

Some components rely on the component to handle session management for multiple logins, and others can only do one (JMS can only connect to a single system).

So if you do a kamelet with jms that does

from websphere mq to activemq

then that would need to have jms1 and jms2 components with their own connection factory.
Rewriting the jms component/endpoint to support multiples would be really complex.

Lets revisit this next week after our duties at work this work

[lburgazzoli]

yeah let revisit it next week

but in general if you have two templates targeting the same jms system (even with the same credentials), then you still need to create two distinct components because you can't derive if they are shared or not from the template context (of course it is not the same for seda)

[davsclaus]

Yeah we may want to add tenant (or some better term) information on components

• multi tenant (seda, log, file, http)
• single tenant (jms, salesforce, aws)

And then for single tenants we would need to create new distinct components if the kamelet use endpoints from same component that would targeted different systems

Anyway some beer and wine and some good nights sleep and next week we forgot all about this and then we have a fresh perspective to come up with a good solution ;)

[lburgazzoli]

I think I could have reasonable solution but will keep it secret till next week to see if it will survive the initial stage

[lburgazzoli]

This can be solved by https://issues.apache.org/jira/browse/CAMEL-16394

[lburgazzoli]

I think that now with the local beans and the kamelet-reify component we have a solution for this