You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kie.apache.org by Enrique Gonzalez Martinez <eg...@apache.org> on 2024/08/02 06:43:56 UTC
[PROPOSAL][WORKFLOW] Human Tasks subsystem
* 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.)
RE: [PROPOSAL][WORKFLOW] Human Tasks subsystem
Posted by Martin Weiler <mw...@ibm.com.INVALID>.
+1
________________________________________
From: Enrique Gonzalez Martinez <el...@gmail.com>
Sent: Friday, August 2, 2024 4:56 AM
To: dev@kie.apache.org
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 <
ftirados@redhat.com> 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 <tz...@apache.org> wrote:
>
> > +1
> >
> > Dňa pi 2. 8. 2024, 12:03 Alex Porcelli <al...@porcelli.me> napísal(a):
> >
> > > +1
> > >
> > >
> > > On Fri, Aug 2, 2024 at 4:13 AM Pere Fernandez (apache) <
> > > pefernan@apache.org>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Fri, 2 Aug 2024 at 08:44, Enrique Gonzalez Martinez <
> > > > egonzalez@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-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > >
> >
>
Re: [PROPOSAL][WORKFLOW] Human Tasks subsystem
Posted by Enrique Gonzalez Martinez <el...@gmail.com>.
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 <
ftirados@redhat.com> 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 <tz...@apache.org> wrote:
>
> > +1
> >
> > Dňa pi 2. 8. 2024, 12:03 Alex Porcelli <al...@porcelli.me> napísal(a):
> >
> > > +1
> > >
> > >
> > > On Fri, Aug 2, 2024 at 4:13 AM Pere Fernandez (apache) <
> > > pefernan@apache.org>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Fri, 2 Aug 2024 at 08:44, Enrique Gonzalez Martinez <
> > > > egonzalez@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-unsubscribe@kie.apache.org
> > > > > For additional commands, e-mail: dev-help@kie.apache.org
> > > >
> > >
> >
>
Re: [PROPOSAL][WORKFLOW] Human Tasks subsystem
Posted by Francisco Javier Tirado Sarti <ft...@redhat.com>.
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 <tz...@apache.org> wrote:
> +1
>
> Dňa pi 2. 8. 2024, 12:03 Alex Porcelli <al...@porcelli.me> napísal(a):
>
> > +1
> >
> >
> > On Fri, Aug 2, 2024 at 4:13 AM Pere Fernandez (apache) <
> > pefernan@apache.org>
> > wrote:
> >
> > > +1
> > >
> > > On Fri, 2 Aug 2024 at 08:44, Enrique Gonzalez Martinez <
> > > egonzalez@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-unsubscribe@kie.apache.org
> > > > For additional commands, e-mail: dev-help@kie.apache.org
> > >
> >
>
Re: [PROPOSAL][WORKFLOW] Human Tasks subsystem
Posted by Tibor Zimányi <tz...@apache.org>.
+1
Dňa pi 2. 8. 2024, 12:03 Alex Porcelli <al...@porcelli.me> napísal(a):
> +1
>
>
> On Fri, Aug 2, 2024 at 4:13 AM Pere Fernandez (apache) <
> pefernan@apache.org>
> wrote:
>
> > +1
> >
> > On Fri, 2 Aug 2024 at 08:44, Enrique Gonzalez Martinez <
> > egonzalez@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-unsubscribe@kie.apache.org
> > > For additional commands, e-mail: dev-help@kie.apache.org
> >
>
Re: [PROPOSAL][WORKFLOW] Human Tasks subsystem
Posted by Alex Porcelli <al...@porcelli.me>.
+1
On Fri, Aug 2, 2024 at 4:13 AM Pere Fernandez (apache) <pe...@apache.org>
wrote:
> +1
>
> On Fri, 2 Aug 2024 at 08:44, Enrique Gonzalez Martinez <
> egonzalez@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-unsubscribe@kie.apache.org
> > For additional commands, e-mail: dev-help@kie.apache.org
>
Re: [PROPOSAL][WORKFLOW] Human Tasks subsystem
Posted by "Pere Fernandez (apache)" <pe...@apache.org>.
+1
On Fri, 2 Aug 2024 at 08:44, Enrique Gonzalez Martinez <eg...@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-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL][WORKFLOW] Human Tasks subsystem
Posted by Jason Porter <li...@apache.org>.
Could we get the link for the doc with the diagram, please?
On 2024/08/02 06:43:56 Enrique Gonzalez Martinez 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-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [PROPOSAL][WORKFLOW] Human Tasks subsystem
Posted by Yeser Amer <ya...@apache.org>.
+1
On 2024/08/02 06:43:56 Enrique Gonzalez Martinez 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-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org