As discussed on slack, I will try to explain the my current use case in detail, which I am trying to migrate to temporal. Attached is a drawing to describe the various parts of the system to help the description. I want to get your inputs on the design before I starting with the implementation.
The initial design which you can see in the attachment is coming from these business requirements:
- A workflow consists of multiple input tasks (T#1, T#2, T#3…T#8) which are organized into task groups. In each task group there can be multiple tasks, which can be fulfilled in parallel)
- Task groups (TG#1, TG#2, TG#4, TG#5, TG#8) are notified sequentially, when the previous task group completed
- A Task group completes when all tasks/inputs within the group have been marked completed (e.g. TG#2 completes when T#2 and T#3 both have been supplied with external input)
- A workflow completes when the last task group is completed
- A task/input has to be able to accept input even before being assigned/notified (e.g. last notification is TG#2 but T#8 wants to provide its input and complete task T#8)
- Previously completed input tasks can be marked as incomplete by a third party user/service and so they have to be reopened while the main workflow is running. This action should make the re-opened task group the current task group (e.g. current task group is TG#5 but T#4 input contains invalid data an administrator has to be able to re-open task T#4 making TG#4 the currently active task group, hence sending out the notification for input completion again for TG#4)
- Having a completed business workflow, an administrator has to be able to reopen tasks, reverting the business workflow to a „running“ status. The notification for input completion should be sent out for the currently new active task group (e.g. after completed workflow, T#4 is deemed incorrect or incomplete, the workflow should be started again, but rehydrating with the already completed task groups, so that only TG#4 is assigned and is required for completion, because TG#1, TG#2, TG#5 and TG#8 are already correct and complete.
- The required inputs for the individual tasks can be provided by either humans (e-mail notification) or by multiple third party services (event notification)
The question which I raised on Slack was due to me trying to tackle the state management and rehydration within replays and or between run IDs. This is where I really confused myself having state within temporal and the database as well.
Side note: The database behind the workflows is used currently as the primary source of truth for the clients and for search and reporting purposes.
I appreciate you taking time to dissect the concept.