Greetings! After several meetings with our client, we finally have a clear picture of the required implementation, so we plan to start development activities next week. Finally we’ll be able to test your product thoroughly.
A small, bullet-point fashion premise:
• The objective is to let users schedule new tasks. Each task is composed of steps, with specific dependencies (eg. Step 2 should happen after step 1 is completed), dictated by the task to be scheduled
• The granularity of the scheduling is the single day: each step can start / end only at the beginning of a day
• To complete each step of a task, resources of different types should be consumed, for a certain amount of time. For instance: in order to complete step 2, you’ll need: “10 hours of Resource A, 20 hours of Resource B, 15 hours of resource C”
• Resources availability can vary every day, but is always known beforehand (at least for what concerns the scheduling period). For instance, if we have to schedule for the next 3 days, we know that we’ll have 50 hours of Resource A for the first day, 40 hours for the second day and 30 hours for the third day: same reasoning for the other resources.
• The daily allocation of the required resources for each task, depending on their availability and on the resource requirements of each task can be performed by our logic, but we should be able to use your scheduler to show the result to the user (both in term of steps duration / start date / end date and in term of resources consumption for each resource type, for each day), so that they can customize (through drag and drop) the start / end of each step of the task. After they have performed some custom changes, the resource allocation part of the chart should be updated to reflect them (we can implement the required calculations)
So, given our requirements, we thought that your example with scheduler pro at this link would be the best fit four our needs:
https://www.bryntum.com/examples/scheduler-pro/resourcehistogram/
Starting from the supplied scheduler pro example, we identified these differences, with respect to the solution that we want to achieve:
1) The task steps shown in the scheduler should not be related (on the rows) to the resources which are being used to complete them, as shown in the example pic: in our specific case, almost every task is completed by consuming different resources, and that would lead to the same step being shown on multiple rows (one for each resource which is being consumed for that task), which is quite unconvenient in our case. The amount of rows should just correspond to the maximum number of steps in parallel (depending on the task). Each row doesn’t represent anything (it’s not a resource)
2) The start date of each step of each task corresponds to the first day in which a resource required for that step has been allocated on that step
3) The end date of each step of each task corresponds to the last day in which a resource was allocated for that step (fulfilling the resource requirements for the step, and so completing it)
4) It should be possible to express the amount available for each resource on a daily basis: as stated before, for each resource, the amount available every day (before a new task is allocated) can vary (for external reasons or because of other tasks already allocated on same days, which use the same resources)
So, then end result should look like this: the allocation of a task, made of three steps (step1, step2, step 3), with certain dependencies, and through the usage of 3 different resources (res. A, res. B and res. C). Ignore the colored bars inside each step: that is just to show that each day, one or more resources are allocated for each step, depending on each step requirements and resource availability.
First things first, we compared the data structures that we would be able to produce and that we would feed the scheduler with (so that we can achieve the desired result) vs the data structures that such example seems to be using, to check for differences. There are a couple of issues that we found, and we’re asking for your help to understand how to handle them.
-list of events: each event is a step, with a start date and a duration (this seems to be fine with respect to the structure and semantic of your events, the only issue is that in the scheduler, as stated, we don’t want each row to be linked to a specific resource, to avoid steps being shown multiple times, if allocated on more than one resource: the number of rows should just correspond to the maximum amount of steps in parallel, depending on step constraints, defined for the task)
-list of resources: as per your data structure, we would also represent a resource with an unique id and a name, but we should also be able to specify the amount available of each resource for each day, since that amount can vary (possibily even through an async callback that the scheduler can invoke every time it needs to know how many hours are available for a certain resource for a specific day)
-list of assignments: here there seem to lie the biggest difference: based on your data structure, an assignment is simply “a resource assigned to an event”. For our logic instead, an assignement is “a resource, assigned on a specific day, for a certain amount of hours, to a specific event”. The same resource can be assigned on the same day to different events, with different amount of hours for each one of them. About this: we have considered generating events dynamically so that each event represent the resource consumption of a certain type, for a specific amount of hours on a set date, in the context of a specific step of a certain task..but that would make us unable to generate the top part of the scheduler..with the "real" step events that compose the task being scheduled, so probably a different solution is required
Could you provide us with some guidance to understand how to handle these differences between the data structures so that we’re able to achieve the desired result?
Thank you