“Skyplanner” duomenų struktūra #
Prieš pradėdami nagrinėti laiko juostas, turime šiek tiek aptarti “Skyplanner” duomenų struktūrą ir tai, kaip viskas veikia po gaubtu. Visa tai bus panaudota vėliau.
Jei integravote savo užsakymo, darbo užsakymo ar darbo vietos duomenis į “Skyplanner”, greičiausiai naudojote bent jau šias API sąsajas:
- phaser-orders
- phaser-Order-rows
- phaser-jobs
Į šias galines nuorodas įterpti duomenys “Skyplanner” vartotojo sąsajoje pateikiami taip:
Įterpę užsakymus į “Skyplanner”, norėsite juos eksportuoti (tai galima padaryti per vartotojo sąsają arba /phaser-orders/export-endpoint) į gamybos planavimo modulį:
Eksportuodama užsakymus “Skyplanner” iš tikrųjų kopijuoja užsakymo duomenis iš vienos duomenų bazės lentelės į kitą. Taigi, jei ką nors pakeisite, pavyzdžiui, naudodami /phaser-orders -endpoint, turėsite dar kartą eksportuoti duomenis, kad juos atnaujintumėte gamybos planavimo programoje. Tai taip pat reiškia, kad norėdami pasiekti užsakymus, kuriuos matote gamybos planavimo lange, turite naudoti skirtingus API galinius taškus!
“Pasikeitę” galiniai taškai yra tokie:
Tai svarbu žinoti, nes, naudodami /timelogs -endpoint, kad registruotumėte gamybos įvykius ir t. t., turite naudoti susijusias esybes, esančias Production Scheduling -endpoint!
Pavyzdžiui, jums reikia production_planning_job_id (pakartokime: production_planning_jobs yra subjektai, prieinami iš /jobs galinio taško), kad galėtumėte nusiųsti naują laiko žurnalą:
Reikalingą production_planning_job_id galite rasti iš /phaser-jobs -endpoint:
Arba iš /job -endpoint:
Laiko žurnalų kūrimas naudojant REST API #
Per API į “Skyplanner” perkeliant laiko juostas į “Skyplanner” naudojamos tos pačios taisyklės ir sistemos, kurios yra vartotojo sąsajoje. Todėl prieš bandant naudoti šią sistemą per API gali būti naudinga susipažinti, kaip ji veikia sąsajoje.
Laiko registro pagrindai #
“Skyplanner” turi keturis laiko registro įvykių tipus:
- shift_begin
- pauzė
- toliau
- shift_end
Shift_begin-event siunčiamas, kai darbas paleidžiamas pirmą kartą. Niekada nesiųskite daugiau nei vieno shift_begin įvykio kiekvienam darbui!
“Paused-event” sustabdo darbą.
“Continued-event” atnaujina sustabdytą darbą.
Shift_end užbaigia darbą. Niekada nesiųskite daugiau nei vieno shift_end įvykio kiekvienam darbui!
Reikalingi laiko žurnalų duomenys:
- person_id
- Galima rasti iš /people-endpoint
- Tai ne tas pats, kas user_id!
- planned_workstation_id
- Darbo vieta, kurioje atliekamas darbas
- Galima rasti iš /workstations-endpoint
- data_laikas
- Įvykio atlikimo laikas
- Formatas: 2024-01-01 10:30:11
Norėdami nurodyti, koks “Skyplanner” laiko žurnalas yra susietas su bet kurios naudojamos išorinės sistemos laiko žurnalu, galite naudoti lauką external_id . Pavyzdžiui, naudodami šį ID galite atlikti GET užklausas, kad surastumėte konkretų “Skyplanner” laiko žurnalą.
Darbo pradžia #
Darbus galite paleisti siųsdami POST užklausą API, pvz., taip:
Nustatydami POST duomenis laiko žurnalams, nustatykite workshift_id kaip 0 ir timelog_finalized kaip true
Darbo sustabdymas #
Sustabdykite darbus siųsdami tokią POST užklausą:
Sustabdytuose laiko žurnaluose galite nustatyti sumą ir faulty_amount. Taip pat atkreipkite dėmesį į laiko žurnalo tipą ir datą_laiką.
Darbo tęsimas #
Štai kaip tęsti sustabdytą laiko žurnalą:
Atkreipkite dėmesį, kad jei bandysite tęsti darbą, kuris buvo baigtas įvykiu shift_end, gausite klaidą.
Darbo pabaiga #
Štai kaip užbaigti darbą naudojant pamainos pabaigos žurnalą:
“shift_end-events” galite nurodyti sumas ir faulty_amount reikšmes, kaip ir “paused-events”. Atkreipkite dėmesį, kad, jei bandysite atlikti shift_end-event užduočiai, kuri nėra vykdoma, gausite klaidą.
Laiko žurnalų atnaujinimas #
Laiko žurnalo duomenis galite atnaujinti siųsdami PUT užklausas į /timelogs-endpoint, pvz., taip:
Atkreipkite dėmesį, kad norėdami atlikti atnaujinimą, turite turėti ir beginTimelog , ir endTimelog duomenų rinkinį. Laiko žurnalai “Skyplanner” saugomi taip: kiekvienas “pilnas” (laiko žurnalas, turintis ir pradžią, ir pabaigą (pvz., pamainos_pradžia / tęsinys ir pertrauka / pamainos_ pabaiga) laiko žurnalas turi atskirą pradžios ir pabaigos vienetą.
Jie suporuojami pagal endloge rastą begin_id reikšmę. Pirmiau pateiktame pavyzdyje beginTimelog turi id reikšmę 1, todėl jo endTimelog turi begin_id reikšmę 1.
Taip pat turite nurodyti person_id ir endTimelog reikšmes kiekvieną kartą, kai atliekate atnaujinimo užklausą, net jei jų nekeičiate.
Alternatyvūs laiko žurnalų sudarymo būdai #
Štai keletas alternatyvių būdų, kaip galite prisijungti prie savo darbo vietų naudodami API.
Logfull #
Jei norite siųsti ir pradžios, ir pabaigos laiko žurnalus vienu prašymu, galite naudoti /timelogs/log-full -endpoint, pvz., taip:
Atkreipkite dėmesį, kaip čia siunčiamos sumos: pirmoji reikšmė “amount” reiškia klaidingą sumą, o antroji – sumą. Ši užklausa sukuria “beginlog” ir “endlog” esybes viena užklausa.
Greitasis žurnalas #
“Greitasis prisijungimas” prie užduoties užbaigia ją viena užklausa, nustato, kad užbaigtų produktų kiekis atitiktų užsakymo elemente nustatytą vertę. Greita registracija atliekama naudojant /timelogs/quick-log -endpoint:
Atkreipkite dėmesį, kad čia reikia nurodyti tik production_planning_job_id, planned_workstation_id ir person_id. Laiko ir sumos reikšmės užpildomos automatiškai. Taip pat atkreipkite dėmesį, kad greitojo registravimo darbai visada baigiami pamainos pabaigos įvykiu (shift_end-event), todėl po greitojo registravimo joks tolesnis registravimas neįmanomas!
