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