Paulo, +1 for this proposal. With the caveat highlighted by Enrique that this won't require any engine deviations, and if needed a new proposal will be sent to this list.
On Wed, Apr 3, 2024 at 11:59 AM Paulo Martins <[email protected]> wrote: > > Thinking about the runtime tooling context, I believe, in the end, we can > have a good set of distributions that complement each other in the > following way: > > - Sonataflow Dev UI extension: Offers an out-of-the-box way to test > workflows and any additional custom resources we decide to support, such as > custom forms and dashboards, during development. > - Serverless Logic Web Tools: Provides a playground environment for new > users and demos, where they can connect their cluster by providing a data > index or gateway API URL, and have access to the runtime tooling without > the need to deploy any additional tooling applications. > - Sonataflow management console: An image that serves a production-ready > webapp containing all runtime tooling features. Provides a way for > developers to include their custom resources, such as custom forms and > dashboards, which the users will be able to access. Includes security > features. Provides information and executes actions by requesting a data > index or gateway API. > > Em ter., 2 de abr. de 2024 às 23:06, Tiago Bento <[email protected]> > escreveu: > > > Hi Paulo, > > > > I understand the ideia is to have an app dedicated exclusively to live > > Serveless Workflows, but I guess it would be nice to understand the > > medium/long term plan for this new console and Serveless Logic Web Tools. > > > > You mentioned they would start very similar, which is fine IMHO, but > > understanding a little more about the purpose of each one individually and > > how they both compose some sort of story would be great to the wider > > audience. > > > > Regards, > > > > Tiago Bento > > > > On Tue, Apr 2, 2024 at 2:34 PM Paulo Martins <[email protected]> wrote: > > > > > The new console creation proposed here is just a new standalone webapp in > > > kie-tools. It does not involve any changes in the runtime nor I expect > > any > > > PRs outside of kie-tools if that is your concern. > > > > > > Inline answers. > > > > > > > Yes, the management console consumes the data index GraphQL API to show > > > > its > > > > > data. > > > > > > > > > > > > > Well you can do that but you are enforcing the user to deploy data > > index. > > > > Just keep in mind the restriction. Any change how data index works or > > any > > > > new change in the system structure should go in a new proposal. > > > > > > > > > > All runtime UIs depend on the data index since a long time ago, even the > > > Dev UI extensions. All the consoles have the ability to show aggregated > > > information of multiple runtime instances by using the data index. > > > > > > > > > > > Although processes and workflows share the same engine, there is a > > need > > > > for > > > > > a different UI because it is consumed in a different way by the user. > > > > > > > > For > > > > > example, the editor which shows the diagram preview with the current > > > > status > > > > > of the process/workflow is different, > > > > > > > > > > > > That is not correct. The engine is consumed in the same way > > independently > > > > on the flavor. Actually jbpm v7 has a way to trigger new processes with > > > > kafka or active mq. > > > > > > > > > > I believe we are mixing engine and UI in the discussion. Just want to > > make > > > sure to clarify that all my observations were made from the tooling side. > > > With that in mind, there are different editors for workflows and > > processes. > > > Each console and Dev UI extension should show their own. > > > > > > > > > > > > > > with workflows there is a different > > > > > way to trigger new instances using cloud events that do not exist on > > > the > > > > > jBPM management console, > > > > > > > > > > > > Keep in mind that the cloud events were there before serverless > > workflow > > > so > > > > that way of triggering things was done for business automation. > > > > > > > > > > They might exist in the engine but this feature is not present in the > > jBPM > > > management console. > > > > > > > > > > the timeline works in a different way, hiding > > > > > automatically generated nodes from the user, some labels are > > different, > > > > and > > > > > so on. > > > > > > > > > > > > > Those are internal aspects of the engine and works in the same manner > > in > > > > both. > > > > > > > > > > I'm not referring to engine aspects, but how the user sees them in the UI > > > is different for each context. > > > > > > > > > > > > > > > > > > > > The Dev UI extensions that we have for jBPMN and Sonataflow already > > > > > diverged in that way because of those differences. > > > > > > > > > > > > There is no divergence except for the representation of the process > > > state. > > > > > > > > > > The divergence is that they are physically different packages. > > > > > > > > > > > > > > Although they share > > > > > several common UI components, each one has their own webapp because > > of > > > > > those specificities. > > > > > > > > > > > > > > > > > > > > > > > > > > Em ter., 2 de abr. de 2024 às 13:56, Enrique Gonzalez Martinez < > > > > > [email protected]> escreveu: > > > > > > > > > > > You wrote you are consuming from data index, isn't it? > > > > > > > > > > > > Related to start triggering things in the workflow engine, is there > > > > > > anything or any new feature regarding those operations that are > > > > different > > > > > > between workflows ? Codegen ? New endpoints ? If not, would not > > mean > > > a > > > > > > duplication with just different ui ? I am just trying to understand > > > the > > > > > > need for a different UI. > > > > > > > > > > > > > > > > > > > > > > > > El mar, 2 abr 2024, 18:49, Paulo Martins <[email protected]> > > > > escribió: > > > > > > > > > > > > > Hi Enrique, > > > > > > > > > > > > > > The existing consoles are for jBPM, the one I'm proposing is for > > > > > > serverless > > > > > > > workflows, which has a different runtime tooling UI then > > processes. > > > > > This > > > > > > > proposal does not cover anything related to data index console. > > > > > > > > > > > > > > > > > > > > > Em ter., 2 de abr. de 2024 às 13:30, Enrique Gonzalez Martinez < > > > > > > > [email protected]> escreveu: > > > > > > > > > > > > > > > There is a mgmt console already to start workflows and tasks. > > > > > > > > > > > > > > > > What would be the difference ? > > > > > > > > > > > > > > > > Regarding data index console i would say we dont have such > > > feature. > > > > > > > > > > > > > > > > I am pretty much about try to have tools separate as we do have > > > the > > > > > > > addons > > > > > > > > separated as well. Having everything in the same place would > > > break > > > > > some > > > > > > > > functionalities depending on the user deployment. > > > > > > > > > > > > > > > > Also keep in mind there are already some component like the > > > gateway > > > > > > that > > > > > > > > centralize some operations. > > > > > > > > > > > > > > > > So i would split things in two different issues. > > > > > > > > > > > > > > > > * Improvements in the current process instance console > > (anything > > > > > > missing) > > > > > > > > * Data index console > > > > > > > > * Any other thing not falling into this category. > > > > > > > > > > > > > > > > > > > > > > > > El mar, 2 abr 2024, 18:21, Paulo Martins <[email protected]> > > > > > > escribió: > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > > > I would say post 10.0.0 as this task has not started yet. > > > > > > > > > > > > > > > > > > > > > > > > > > > Em ter., 2 de abr. de 2024 às 11:46, Alex Porcelli < > > > > > [email protected] > > > > > > > > > > > > > > > > escreveu: > > > > > > > > > > > > > > > > > > > Paulo, > > > > > > > > > > > > > > > > > > > > Is this a proposal for post or pre 10.0.0? > > > > > > > > > > > > > > > > > > > > On Tue, Apr 2, 2024 at 10:34 AM Paulo Martins < > > > > > [email protected]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hello everyone, > > > > > > > > > > > > > > > > > > > > > > I am proposing we create a new management console for > > > > workflows > > > > > > in > > > > > > > > the > > > > > > > > > > > incubator-kie-tools repository. For its first version, it > > > > would > > > > > > > have > > > > > > > > > the > > > > > > > > > > > same features provided in the Serverless Logic Web Tools, > > > > like > > > > > > > > workflow > > > > > > > > > > > instances and definitions list, with the possibility to > > > start > > > > > > > > workflows > > > > > > > > > > by > > > > > > > > > > > their definitions or triggering events. All information > > > would > > > > > > come > > > > > > > > > from a > > > > > > > > > > > data-index, whose URL would be passed on as an > > environment > > > > > > > variable. > > > > > > > > > The > > > > > > > > > > > added value of this new distribution is the offering of > > > > runtime > > > > > > > > tooling > > > > > > > > > > in > > > > > > > > > > > production environments. > > > > > > > > > > > > > > > > > > > > > > The following packages would be created: > > > > > > > > > > > - sonataflow-management-console-webapp: Similarly to > > what > > > > was > > > > > > done > > > > > > > > for > > > > > > > > > > the > > > > > > > > > > > Sonataflow Dev UI extension, a webapp containing all the > > > UI, > > > > > > > reusing > > > > > > > > > > > already existent runtime tools components. > > > > > > > > > > > - sonataflow-management-console-image: New image to > > serve > > > > the > > > > > > > > webapp. > > > > > > > > > > > - sonataflow-management-console-image-env: Image > > > environment > > > > > > > > > variables. > > > > > > > > > > > > > > > > > > > > > > Kind Regards, > > > > > > > > > > > Paulo Martins > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
