+1
On Fri, Aug 2, 2024 at 4:13 AM Pere Fernandez (apache) <pefer...@apache.org> wrote: > +1 > > On Fri, 2 Aug 2024 at 08:44, Enrique Gonzalez Martinez < > egonza...@apache.org> > 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: dev-unsubscr...@kie.apache.org > > For additional commands, e-mail: dev-h...@kie.apache.org >
