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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
