Skills and requirements#
This guide shows how to staff tasks by skill: describe who can do what, state what each task needs, and get slots that Project#suggestAssignments fills. It also covers how earlier assignments stay attached to their requirements from one run to the next.
How the skill layer works#
The scheduling engine doesn't know about skills. Auto-assignment works on slots: one place for one person on one task, with a list of resources allowed to take it. The skill layer, SkillLayer.slots, builds those slots from the data you already work with: workers and their skills. It ships in the same JAR and package as the engine.
Three inputs go into SkillLayer.slots:
- The accepted state of a solved
Project. The skill layer reads its scheduled leaf tasks, resources and active assignments throughProject#roster. - A
PoolofWorkers. Each worker is a resource id plus a list ofSkills. A skill value is0/1for yes-or-no skills, or an integer grade (1 = junior, 2 = senior, and so on).Skill.valuedefaults to1.0. Pool order is the tie-break preference. - A list of
Requirements. A requirement says "task T needscountpeople who satisfy all of theseSkillMatches, each booked atunits". The call takes aVec<Requirement>or anyCollection, soList.of(...)works.
slots returns a Vec<Slot>, ready to pass to suggestAssignments:
- Each requirement becomes
countslots with ids"<requirement id>#1","#2"and so on, in requirement order.SkillLayer.slotIdbuilds the same string. allowedlists the pool workers that pass every match of the requirement, in pool order.valueis the requirement'sunits: the rate a new assignment books.assignmentnames the existing assignment that already fills the slot, or isnull. See Binding existing assignments.
A slot's id is also the id of the assignment that fills it. After you commit a proposal, the task carries assignments named be#1, be#2, and the next slots call finds them by id. That's what keeps staffing stable across runs. It also means a requirement id belongs to its task: reuse be on another task after a commit and slots refuses it.
Skills, pools and requirements aren't stored in ProjectData. You pass them on every call, so they can come from wherever your app keeps them. slots reads the project and never changes it.
Pools and skills#
Build a pool, describe what each task needs, and turn both into slots:
;
;
Output:
be#1 on api: allowed [ann, bob], value 1.0
fe#1 on ui: allowed [ann, cat], value 1.0
Ann has both skills, so she's eligible for both slots. Nothing is assigned yet: slots only says who may take each place. Choosing who does is the job of suggestAssignments.
A worker's resource must name a resource in the project, and each worker appears once. A worker can be in the pool without being eligible for anything, and a project resource can stay out of the pool. A resource outside the pool is never offered for a slot.
Requirements and matches#
new Requirement(id, task, matches) creates one slot at full rate (count 1, units 1.0, assignments null). Use withCount and withUnits to ask for more people or a lower rate. A SkillMatch compares a worker's skill value with a number:
| Factory | Holds when |
|---|---|
SkillMatch.atLeast(skill, v) |
worker value >= v |
SkillMatch.noMore(skill, v) |
worker value <= v |
SkillMatch.equal(skill, v) |
worker value == v |
All three are inclusive. A skill the worker doesn't list counts as 0, so noMore(Id.str("qa"), 0.0) means "not a tester". A requirement with several matches needs all of them. A requirement with an empty match list allows every worker in the pool. To test one worker against one match, call SkillMatch#holds(worker).
;
;
Output:
be#1: value 0.5, allowed [ann, bob]
be#2: value 0.5, allowed [ann, bob]
qa#1: value 1.0, allowed [cat]
qa-jr#1: value 1.0, allowed [ann, dan]
ops#1: value 1.0, allowed [bob]
review#1: value 1.0, allowed [bob]
withCount(2) gives two slots, be#1 and be#2, each booking half-time. Grades turn "senior tester" and "junior tester" into atLeast and equal matches on the same skill. review excludes Ann, Cat and Dan because each of them has a QA grade above 0.
A slot list can allow the same person on several slots of one task. suggestAssignments never puts one resource on a task twice, so Ann can't end up in both be#1 and be#2.
Binding existing assignments#
When the task already has active assignments, slots attaches them to slots, so a filled place isn't offered again. Binding runs per task, over all requirements on that task, in three steps:
- Slot id. An assignment whose id is one of the requirement's slot ids (
be#2) binds to that slot. This is how assignments created by an earliersuggestAssignmentsrun reconnect to their slots. It binds even when the resource no longer matches. The slot is then broken. - Explicit list. A non-null
assignmentslist on a requirement replaces automatic binding for it. Listed entries take the remaining slots in order, and leftover slots stay empty. An empty list leaves every slot empty. - Matching. The task's remaining assignments go to the empty slots of requirements whose
assignmentsisnull. An assignment can go to a slot only when its resource is in the slot'sallowed. The engine runs a maximum bipartite matching in input order. It fills as many slots as possible instead of giving each slot the first fit.
Here Ann (backend and frontend) and Bob (backend only) already work on api under ids the skill layer didn't create:
;
;
;
Output:
matching: [be#1 <- a2, fe#1 <- a1]
explicit: [be#1 <- a1, be#2 empty, fe#1 empty]
empty list: [be#1 empty, fe#1 <- a1]
A greedy pass would give be to Ann, the first backend assignment, and leave fe empty. The matching gives backend to Bob so Ann can cover frontend. The explicit list pins a1 to be#1. Bob's a2 can't fill fe#1, so that slot stays empty. With an empty list, be starts empty and Ann's assignment goes to fe.
The example changes copies made with deepClone(), because the withX setters change the record in place and return the same object.
An assignment that ends up in no slot stays on the task. It still blocks its resource for the task's other slots, and suggestAssignments never repairs or moves it.
slots checks explicit lists up front:
- At most
countentries, each an active assignment on the requirement's task, and each bound once. - If an assignment carries one of the requirement's slot ids, the list must name it. It keeps its own slot.
From slots to suggestions#
Pass the slots straight to Project#suggestAssignments, commit the proposal with apply, and reschedule. The next run with the same requirements binds the committed assignments by slot id, so the proposal stays stable. When a worker's skills change, the bound slot becomes broken, and the BROKEN target repairs it:
;
;
;
Output:
pass 0: be-ui#1 -> ann
be-api#1 <- a2
be-ui#1 <- be-ui#1
run 2: 0 steps
invalid: [be-ui#1]
pass 0: be-ui#1 ann -> bob
Run 1 fills be-ui#1 with Ann. Bob comes first in the pool, but he's already busy on api. The committed assignment gets the slot's id. In run 2 it binds back to its slot, and with every target on there's nothing to improve. In run 3 Ann no longer has the backend skill. withTargets(List.of()) only reports the broken slot in invalid. The full run repairs it by moving the assignment to Bob.
Some things to keep in mind:
slotsneeds a solved, clean project. Afterapply, callsolve(null, …)before you build slots again.suggestAssignmentschecks the slots again: unknown tasks or resources, duplicate slot ids, and a slot id that is already an assignment on another task are errors. Slots fromslotspass these checks, unless the project changed in between.- Targets,
fixedassignments,newResourcePenalty, leveled scoring and the step log are covered in Suggesting assignments. - To keep a person on a slot whatever the load, add the slot's assignment id to
SuggestOptions.fixed.
Errors#
SkillLayer.slots throws an unchecked MatchException with two subclasses:
MatchException.Project: the project is unsolved, or it has unsolved edits afterapply.code()returnsProjectError.NO_BASELINE, anderrorholds the wrappedProjectException.slotstakes no baseline token, so there's no stale-baseline case.MatchException.Invalid: bad pool or requirement input. Thepathanddetailfields hold the location and the reason, andgetMessage()is"<path>: <detail>".
A null argument throws NullPointerException.
MatchException isn't a PlenException. Its simple name also clashes with java.lang.MatchException, so import org.dhtmlx.plen.*; alone leaves MatchException ambiguous. Add a single-type import:
;
;
;
Output:
project error: NO_BASELINE
invalid: requirements[0].count: must be at least 1
The path points at the offending item:
| Path | Reason |
|---|---|
pool.workers[i].resource |
Unknown resource, or a worker listed twice |
pool.workers[i].skills[j].id |
A skill listed twice for one worker |
pool.workers[i].skills[j].value |
Not a finite number |
requirements[i].id |
Duplicate requirement id, or one of its slot ids is an assignment on another task |
requirements[i].task |
Unknown or unscheduled task |
requirements[i].count |
0 |
requirements[i].units |
Not finite, or 0 or less |
requirements[i].matches[j].value |
Not a finite number |
requirements[i].assignments |
More entries than count, or an assignment with this requirement's slot id is left out |
requirements[i].assignments[k] |
Unknown or inactive assignment, on another task, or bound twice (the message names the other requirement when there is one) |
slots throws on the first problem it finds and builds nothing. It never changes the project, so you can fix the input and call again. To run the pool checks alone against a Roster, call SkillLayer.validatePool(roster, pool).
toPlenException() converts either subclass into the matching engine exception: Invalid becomes a validation InputException with the same path, and Project returns the wrapped ProjectException. Convert at the call site and one catch chain then covers both calls:
;
;
;
Output:
project error: NO_BASELINE
See Error handling for the engine's exception model.