search

KaotoIO / kaoto-ui

Frontend for the Kaoto project to provide an easy-to-use integration framework based on Apache Camel.
https://www.kaoto.io
Apache License 2.0
88 stars 44 forks source link

Templates for Integrations #19

Open kahboom opened 3 years ago

kahboom commented 3 years ago

As a user, I would like to have a list of common workflows that can be used as a template, which would save time in setting up integrations or getting more familiar with how to use Kaoto.

Similar to how most workflow processing apps work, like LucidChart.

Example: New order in Shopify -> create Salesforce contact -> create Trello card

Delawen commented 1 year ago

Proposed approach to this feature:

1.- Create a new endpoint in the backend that provides a list of templates that can be filtered by DSL, starting step, ending step, and by text in the title of description of the template. 2.- Create a wizard in the frontend that shows the list of templates and allows to filter them based on DSL, starting step, ending step, or text. Once a template is selected, it will clean up the canvas and load it.

Format to store/share the template:

Option a: Just the source code The template is just a source code that gets added to the canvas. Afterwards, the user can modify it freely, with no restrictions. This is useful for example purposes in which the user just kickstart something and then experiment and evolve from there.

We more or less already have this implemented with the load file/save file features.

Option b: A new format The template is more than just source code. This is useful to guide users when building their integrations.

It contains more information, like the constraints on what steps can be added on each position or what parts must be fixed in the source code (annotations, labels, regexp for title,...??). This can be forced by the backend when showing the mini catalog, or syncing the source code based on some annotation that stores the name/id of the template.

Without any constraints defined in the template, this would work (user-wise) as Option A.

We need to agree on an agnostic format on how to define this constraints and make sure the constraints can be either enforced by the backend (who knows the full template) or can be passed cleanly to the frontend in an agnostic way.