Implement On-demand scheduling

[krashish8]

Give back the schedule instantly whenever a job/shipment is added to the project.

First, this requires merging some API endpoints:

• jobs and jobs_time_window
• shipments and shipments_time_windows
• breaks and breaks_time_window.
• Might require merging vehicle and vehicle_breaks.

It will be good if a task and its time windows are supplied at once in a request, and then, that task is scheduled. Some possibilities:

• Task and its time window have separate endpoint: Whenever a task is added, schedule it without any time window constraint. Now, whenever a time window is added, reschedule it according to that time window constraint.
• Task and its time window have separate endpoint: Schedule a task only when its time windows are added.
• Task and its time window have same endpoint: Add a time window field in the task API endpoint, instead of a separate task_time_window endpoint. Then schedule a task whenever it is added/edited, because always the time windows will be supplied along with a task.

I think the third option is better, and this requires merging these API endpoints.

This can be directly done only for the API endpoint. However, a better way would be to use time_window_type in vrprouting itself, instead of creating separate time window tables, and then corresponding changes can be made in pg_scheduleserv. But this might not be straightforward as it requires dealing with types on a PostgreSQL extension, which we have not done yet in either pgrouting or vrprouting.

Apart from this, there are several questions and some (possible) answers, related to on-demand scheduling. Do share your thoughts on these.

Q. What to do if a job/shipment is added, but no vehicle is present? Don’t schedule it. Mark it as “unscheduled”.

Q. Shall we allow users to reschedule a job/shipment later? Yes - two options:

1. Reschedule if it is “unscheduled”.
2. Reschedule if it is already scheduled by deleting the old schedule.

Q. What to do when a vehicle is added? Don’t reschedule. The vehicle will only serve future tasks.

Q. What to do when an existing vehicle is edited (or deleted), say time window, or capacity constraints, or breaks? This will require rescheduling ALL the tasks, including the already scheduled ones. Another way would be to restrict editing vehicle fields.

Q. Deleting a job/shipment? Change the status to “deleted”, and delete the corresponding schedule.

Q. Editing a field of job/shipment. Three possible options:

1. Directly reschedule the task, and give back a new schedule (requires deleting & creating schedules).
2. Do not allow editing if the job is already scheduled, so give back an error message. This would mean that first the schedule needs to be deleted, and then only editing is possible.
3. Do the edit, mark it as “dirty” (indicating that rescheduling is needed).

In addition, we can allow to schedule tasks at the end by manual trigger:

• Allow scheduling ALL the tasks (Requires deleting & creating schedules of all tasks)
• Only “dirty” tasks (Requires deleting & creating schedules of dirty tasks)
• Only “unscheduled” tasks
• “Dirty” + “unscheduled” tasks.

Dirty = user marked this as dirty, or maybe the task is edited (point 3 of the above question). Unscheduled = could not be scheduled by VROOM

Again, based on #15, we need to keep in mind that multiple scheduling may make the existing task unallocated, or change its schedule.

[dkastl]

Q. How to deal with tasks "in the past" or before a specific date/time? This is some kind of "real-time" scenario. We could allow to specify a timestamp, and (re-)scheduling will only affect orders after that time. A complicated case is, if a shipment lies before and after that timestamp.

Q. Do we want to allow the API to also document a job/shipment? Currently there might be a status not scheduled and scheduled. But it could be helpful to also keep track of in progress and completed. in progress is a tricky state, especially for shipments.

In general scheduling with existing allocations should be done in a way, that whatever task has been allocated before should not be dropped from the schedule later. If a full rescheduling is done on purpose, then this could be done by removing all tasks from the schedule before.