Šaltinis: vidinė medžiaga (Giedrius Lukoševičius). Papildo techninę API nuorodą: rivile-erp-automatizavimo-api.html. Pritaikymo kontekstas: rivile-erp-customization-konceptas.html. Infrastruktūra, ribos, greitaveika: rivile-erp-infrastruktura-ribos-greitaveika.html.
Projekto kontekstas: atstovų mokymas apie automatizavimą ir pritaikymą; organizacija ir formatas — Tema 1 · Įvadas ir planas.
| Elementas | Aprašymas |
|---|---|
| Metaduomenys | Pavadinimas, kodas, įmonė, savininkas, pranešimai apie klaidas, isSystem ir kt. |
| Trigeriai ir įvykiai | Kas paleidžia procesą (įvykis, laikas, webhook, UI, rankinis). |
| Kontekstas ir parametrai | Duomenys scenarijui: kas įvyko, būsena, papildomi parametrai. |
| Scenarijus | JavaScript: transformacijos, duomenų gavimas, veiksmų kvietimas. |
| Veiksmai | Sisteminės mutacijos / funkcijos (vidinės ir išorinės). |
| Auditas | Vykdymo istorija, kontekstas, rezultatai. |
| Apribojimai ir resursai | Laikas, lygiagretumas, eilės, apsauga nuo perteklinio naudojimo. |
Koncepcija: pritaikytas automatizavimas = trigeris + (sąlygos / transformacija) + veiksmai, su auditu ir resursų ribomis.
| Tipas | Pavyzdžiai / pastabos |
|---|---|
| Įvykio trigeris | Pvz. sukurtas PVM dokumentas, patvirtintas pirkimas, atliktas atsargų judėjimas. |
| Suplanuotas (CRON) | Kasdien / savaitę / mėnesį — ataskaitos, priminimai. |
| Webhook | Išorinė sistema siunčia duomenis / užklausą (pvz. e‑komercija → užsakymo būsena). |
| UI trigeris | Mygtukas, forma, lauko interaktyvus pasikeitimas. |
| Rankinis trigeris | Vartotojas paleidžia iš konkretaus UI, pvz. formos Papildomi veiksmai („Siųsti per EDI“, „Sujungti sąskaitas“). Rankiniam trigeriui turi būti realūs frontendo formų kontekstai, iš kurių galima paleisti. |
Papildomas parametrizavimas (UI): rankiniam paleidimui gali būti parametrai kaip ataskaitose — modalas su laukais prieš vykdymą.
Po įvykio scenarijus gauna duomenis apie: įvykį, objektą (pvz. sąskaitą), vartotoją, inicijuotoją (automatizavimas, API, vartotojas), organizaciją ir įmonę; webhook gali turėti papildomą kontekstą.
Projekto kataloge
scripts/
saugomi automatizavimo apibrėžimų JSON eksportai (scriptContent, paramsFormSchema, exampleData). Ten pat aprašyta: objektas initial, formos laukai, try/catch ir UserError, output, *`log.`** naudojimas — pagal tikrus failus.
Vykdymo taisyklės:
Rekomendacija: globalios taisyklės įvykiams be griežto įmonės konteksto.
Po trigerio ir sąlygų vykdomi sistemiškai apibrėžti veiksmai (skirtingi trigerių tipams).
Pavyzdžiai: el. laiškai, įrašų atnaujinimas, ataskaitos, išoriniai API, atsargų rezervavimas ir kt.
Gero veiksmo specifikacijai naudinga aprašyti: paskirtį, įvestis / išvestis, vykdymą (sinchronas / asinchronas), klaidas, žurnalą, pavyzdžius, saugumą, priklausomybes. Bendras Automation lygis async vs sync — žr. §10.
Kas rodomas kaip „kas pakeitė“ duomenis priklauso nuo paleidimo būdo — žr. §12 (inicijuotojas vs scheduler / automation naudotojas).
Fiksuoti bent:
| Sritis | Reikalavimai (santrauka) |
|---|---|
| Vykdymo laikas | Administratorius gali nustatyti max. laiką; viršijus — nutraukti, aiškios klaidos, galimybė scenarijui „išeiti tvarkingai“. Automation sesija: 15 min — žr. §13. |
| Naudojimo stebėsena | Stebėti resursus; vykdymo laikas per organizaciją / įmonę (sąskaitų faktūrų / kainodaros kontekstas). |
| Resursų kvotos | CPU, atmintis ir kt. — protingos ribos debesų aplinkoje. Automation užduotis: atminties riba iki 2 GB; dideli JSON ir lygiagretumas — žr. §13. |
| Lygiagretumas | Riboti vienu metu vykstančių automatizavimų skaičių klientui. |
| Prioritetai ir eilės | Eilių sistema, kai resursų mažai. |
| Debesų masteliai | Elastingas skalavimas, monitoringas ir aliarmai prie slenksčių. |
Užduočių rūšys ir atskiros eilės. Automation, Email Template ir Reporting užduotys paskirstomos į skirtingas eilės (kiekvienas tipas turi savą eilių visumą). Kiekviena tokia eilė toliau skirstoma į mažesnes eiles pagal prioritetą (pvz. HIGH / MEDIUM / LOW ar analogiška politika aplinkoje).
Paralelumas tarp eilių. Kiekvieną eilę aptarnauja atskiri procesai (workers). Todėl skirtingose eilėse esančios užduotys gali būti vykdomos lygiagrečiai — viena eilė neblokuoja kitos tik todėl, kad „priešakyje“ stovi kitos rūšies darbai.
Procesoriai vienoje eilėje. Kiekviena eilė turi bent vieną procesorių (vieną lygiagretumo vienetą toje eilėje).
| Procesorių skaičius eilėje | Elgsena toje pačioje eilėje |
|---|---|
| 1 | Užduotys vykdomos nuosekliai (viena po kitos). |
| > 1 | Toje pačioje eilėje kelios užduotys gali vykti lygiagrečiai (kol leidžia procesorių skaičius). |
Ką tai reiškia konsultantui: laukimo laikas priklauso ne tik nuo prioriteto, bet ir nuo to, kurioje eilėje yra užduotis ir kiek procesorių ten sukonfigūruota — piko metu ilga „eilė prie vieno procesoriaus“ vis tiek reiškia nuoseklų vykdymą.
Du bendri būdai pagreitinti (sutrumpinti laukimą iki to momento, kai užduotis pradedama vykdyti):
Dedikuotos eilės. Tam tikras užduotis galima nukreipti į atskiras, dedikuotas eilės — tada jos nebestovi bendroje eilėje su kitomis to paties tipo užduotimis ir „apeina“ ten laukiančius procesus. Praktinė pasekmė: trumpesnis laikas iki vykdymo pradžios (ne būtinai trumpesnė pati operacija).
Procesorių skaičius. Galima padidinti procesorių skaičių prie pasirinktų eilių — daugiau lygiagretumo toje pačioje eilėje, trumpesnis laukimo laikas iki pradžios, kol apkrova nepasiekia naujos pusiausvyros.
Pastaba: šie instrumentai yra konfigūracijos / veiklos lygio (administravimas, debesų politika), ne vien scenarijaus JS optimizavimas; su klientu verta susieti lūkesčius (pikas, masiniai CRON, dideli ataskaitų paketai) ir stebėti auditą / eilių būseną, jei tokia diagnostika prieinama.
| Rūšis | Elgsena |
|---|---|
| Async | Vyksta nepriklausomai nuo pagrindinių ERP procesų (dokumento sukūrimas, patvirtinimas, atšaukimas ir pan.). Fono logika — transakcija ar vartotojo sesija gali judėti toliau, o automatizavimas užbaigiamas atskirai (eilė, užduotis). |
| Sync | Kol automatizavimas vyksta, sistema ir vartotojas laukia jo pabaigos (blokuojantis kelias). |
Konsultantui: sync tinka trumpiems, kritiniams keliams, kur reikia užtikrinti prieš tęsiant; async — kai negalima „laikyti“ UI ar transakcijos ilgai.
Scenarijus gali kviesti kitą automatizavimą, tas — trečią ir t. t. Tai leidžia komponuoti logiką, bet kelia riziką begaliniam ciklui (A → B → A → …).
Apsauga: veikia algoritmas, kuris skaičiuoja, kiek kartų tame pačiame cikle buvo pakviestas tėvinis procesas. Jei ciklas pasikartoja jau trečią kartą, vykdymas nutraukiamas (apsauga nuo amžino ciklo).
Sesija. Automation scenarijus gali vykti tol, kol galioja automatizavimo sesija. Sesijos trukmė: 15 minučių. Pasibaigus sesijai, tolimesnis vykdymas negalimas toje pačioje sesijoje — vertinti ilgų scenarijų skaidymą, eiles ar async modelį.
Lygiagretumas scenarijuje (Automation Type). Scenarijuje galima sukurti kelias async gijas ir vykdyti skaičiavimus ar užklausas lygiagrečiai. Tai naudinga, kai lėtai atsako išoriniai resursai: kol jie grąžina duomenis, jūsų pusėje paraleliai vykdomi kiti darbai.
Atmintis. Lygiagretumas didina vienu metu naudojamą atmintį. Vienai automatizavimo užduočiai galioja riba: ne daugiau kaip 2 GB. Skaičius atrodo didelis, bet:
Rekomendacija: vertinti paralelumą ir duomenų tūrį; vengti nereikalingų kopijų, skaidyti paketus, kur įmanoma srautuoti ar apdoroti dalimis.