+1 ________________________________________ From: Enrique Gonzalez Martinez <[email protected]> Sent: Friday, August 2, 2024 4:56 AM To: [email protected] Subject: [EXTERNAL] Re: [PROPOSAL][WORKFLOW] Human Tasks subsystem
User task has been always a subsystem within jbpm realm and there is a good reason behind it. 1. It bloats the process state with information regarding user task 2. They have different lifecycles 3. They are right now mixed in the process state execution and computation 4. They have diff requirements in terms of security 5 it is aligned with other proposals to set the engine as minimum set of execution nodes. User tasks sre not required in other flavours like servless workflow. 6. Subsystem is how the kogito is though for things like this. Communication is a trade off. Job service is already designed so it should go in the same fashion Removing the user tasks lifecycle from the workflow execution is a heavy requirement for bpmn as it will impact heavily the performance and database roundtrips and latency. El vie, 2 ago 2024, 12:24, Francisco Javier Tirado Sarti < [email protected]> escribió: > Although the proposal is conceptually good (user task can be modelled as a > different microservice which communicates with the engine remotely or > embedded), I'm wondering what are the real advantages we are going to > obtain with such a big change? > Because we already have task deadlines, task persistence support, task > customization, task events, task rest interface.... > And I feel this conversion into a separate microservice will complicate > transaction handling (which is already complicated as discussed in a > different e-mail thread) > I think it is more important to first discuss which human task model we > want to have, if the flexible Kogito one that Maciej implemented after his > experience with V7 or the "orchestrated" v7 one that he removed. > > > > On Fri, Aug 2, 2024 at 12:04 PM Tibor Zimányi <[email protected]> wrote: > > > +1 > > > > Dňa pi 2. 8. 2024, 12:03 Alex Porcelli <[email protected]> napísal(a): > > > > > +1 > > > > > > > > > On Fri, Aug 2, 2024 at 4:13 AM Pere Fernandez (apache) < > > > [email protected]> > > > wrote: > > > > > > > +1 > > > > > > > > On Fri, 2 Aug 2024 at 08:44, Enrique Gonzalez Martinez < > > > > [email protected]> > > > > wrote: > > > > > > > > > * Human Task as subsystem * > > > > > > > > > > This document describes how to make the human task as a subsystem. > > > > > > > > > > At present workflow runtime and human task runtime is entangled > > > > > causing several problems within the workflow engine processing. > Also, > > > > > other flavors of runtime do not have human tasks in their execution > > > > > model. > > > > > > > > > > - Internal lifecycle causes pauses in workflow processing. > > > > > - It cannot be used as a deployable subsystem. > > > > > - Events and listeners are in the same side of the engine > > > > > - It needs to evolve at different pace from the engine > > > > > - It requires different security requirements from the engine (like > > > > > SSO in case of human task or identity propagation) > > > > > > > > > > * Constraints * > > > > > > > > > > The constraints for this work are: > > > > > > > > > > - The lifecycle of the human task should be independent of the > > workflow > > > > > engine. > > > > > - It should be able to not be deployed with the workflow. > > > > > - It should have its events independent from the engine > > > > > - It has different security requirements from the engine. We need > to > > > > > properly identify the user logged in. > > > > > - It should be able to evolve at a different pace to avoid impact > in > > > > > the engine. (the closer to the user the fastest pace requires) > > > > > - It should be able to be deployable in an in-vm or distributed > > > > > environment like other subsystems. Human tasks can be shared among > > all > > > > > deployments, saving deployments and size. > > > > > - It should support storage. > > > > > - Assignment strategies > > > > > - Bulk operations > > > > > - Task notifications > > > > > - Deadlines > > > > > - Transaction integration with the runtime engine. > > > > > > > > > > * Architecture * > > > > > Look at doc apache to check diagram > > > > > > > > > > - As another subsystem the system will have the same approach > through > > > > > the HumanNodeInstanceImpl. > > > > > - UserTaskService will be the interfaces plus listeners and events > > > > > - Transport will be responsible for in-vm or distributed > > communication > > > > > - UserTaskImpl will be the implementation itself. > > > > > > > > > > * Risk Assessment * > > > > > > > > > > The idea would be to create a new project in a kogito app called > > > > > usertask. This will be able to be deployed as a subsystem or in > > > > > embedded mode. This subsystem is similar in requirements as the > jobs. > > > > > > > > > > Communication types requirements: It has two different ways of > > > > > communication > > > > > - Lifecycle: create the human task from the engine (this was > done > > > > > by rest in the case of jobs) > > > > > - Events: produce events like transitions, outputs, inputs, > > > > > assignments... > > > > > > > > > > Communication channels: > > > > > - In-vm: when deployed in compact architecture > > > > > - Streams: when deployed in distributed architecture > > > > > > > > > > Rest endpoints for user tasks live data modification. > > > > > SSO support > > > > > User Impersonation (v7 features) > > > > > Persistence support (database only for now, pgsql.) > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > >
