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