Evolution of scheduling tasks

• Status: not accepted
• Proposition by: Artur Wojnar
• Approved by: Artur Wojnar, Andres Lamont
• Date: 2024-05-14

See the story.

Context and Problem Statement

We want to be able to:

1. Schedule tasks for a patient on specific date (not immediately as currently)
2. Schedule tasks for a patient when they complete a specific experiment
3. Schedule given experiment more than once

Decision Outcome

See the diagrams.

1. Right now User Service handles, on AddPatientHandler, scheduling experiment features
2. So that means for us the direct scheduling (immediate)
3. The evolution here is about decoupling of the scheduling part off the User Service. Experiment Service is taking over as it already "talks" with the Scheduler
4. To keep the current model we have to make the User Service sending a command like ScheduleDirectly that'd be handled by the Experiment Service
5. User Service can, besides the ScheduleDirectly command, send also other two: ScheduleByStartDate and ScheduleByExperimentCompletion
6. Handling the start date option consists of scheduling an one-off message fired on that date. The message will be ScheduleDirectly command
7. Handling the ScheduleByExperimentCompletion consists of saving the fact that completion of experiment X by patient Y should result in executing ScheduleDirectly command. So that part has to take care off checking completed experiments (ExperimentAdded event) and react accordingly on them if stored infiormation match.
8. Scheduling a given experiment many times is possible with the current architecure. All that has to be done is changing the frontend.