Finite State Machine workflow is implemented in Groovy
- state is stored in the business object related to workflow(machine), not in an extra workflow generic object. Multiple workflows could be defined for one business object, it means that for each workflow own state field should be used
- one state per workflow execution (no parallelism)
- actions are executed in the transition, not in the node/state
- no event sending inside the workflow itself (in action)
- no variables in state workflow: all variables/data need to be stored in the business objects
- events: visible/available in UI as action buttons for the user
- workflow definition stored as JSON
- guard support (transition/event availability is defined via condition/expression/function = guard)
- hierarchical states are not supported
The following things will be implemented later as extensions/helpers (separate sibling library) or in specific application:
- automatic transitions
- task list is based on domain object
- graphical editor
- logging
- analysis
P.S. basic ideas on how FSM API looks like are taken from fsm-as-promised
FSM core could be found here here
Workflow Transition History is implemented as separate library. You can find more information here.
How I can run demo application in development mode?
make start
How I can build demo application?
make build
 |
Alexey Sergeev |
|---|---|
 |
Kirill Volkovich |
 |
Egor Stambakio |
 |
Dmitry Divin |
Contributing are welcome. We need YOU! 🤘