Rivile ERP — infrastruktūra, ribos ir greitaveika (mokymams)

Rivile ERP — infrastruktūra, ribos ir greitaveika (mokymams)

Šis tekstas padeda atstovams ir konsultantams paaiškinti klientams, kodėl tam tikros užduotys gali užtrukti, būti nutrauktos pagal laiką arba ribojamos pagal kiekį — be „sistemos kaltės“ mitologijos, bet su aiškiu kontekstu: bendras debesis, API sutartys, eilės ir duomenų apimtys.

Susiję dokumentai

Dokumentas Ką ten rasti
Tema 1 · Įvadas ir planas Mokymų formatas ir temų medis — Tema 1–12 skaidrėse; įvadas ir formatas atskirai Tema 1, ERP objektas JSON — Tema 2.
rivile-erp-architektura-bendra.html Visa architektūra viename paveiksle: frontend, K8s, REST/GQL, Spring, Artemis, Axon, DB
rivile-erp-duomenu-istraukimas-keliai-ribos.html Keturi keliai (Reporting, Automation, Data Export, BI): eilučių ir laiko ribos, spausdinimas vs eksportas
rivile-erp-guide-api.html Viešojo REST API skaičiai: 100 įrašų GET, 5 MB POST/PUT, ~5 min atsakymo laikas
rivile-erp-automatizavimo-konceptas.html Automatizavimų eilės, prioritetai, lygiagretumas, resursai
rivile-erp-data-export-async.html Kodėl didelis eksportas vyksta ne sinchroniškai (užduotys, failas)
rivile-erp-graphql-overview.html Klaidų tipai (DEADLINE_EXCEEDED, apkrovos ribojimas schemoje)

1. Kodėl iš viso yra ribų?

Priežastis Trumpai
Bendri resursai Kelios organizacijos naudoja tą pačią platformą — būtina spravedingumas (viena organizacija ne„suvalgo“ visų CPU ir DB ryšių).
Stabilumas Begalinės užklausos ar milžiniški atsakymai gali nulaužti darbines eilutes, atmintį ar DB — ribos saugo visus.
Tinklo realybė HTTP užklausa negali kabėti amžinai: tarp naršyklės, balansuotojo ir servisų yra timeout sluoksniai.
Kaina ir planas Debesis ir pralaida kainuoja; tam tikri limitai siejami su prenumerata / moduliais (pvz. funkcijų naudojimo apskaita schemoje).
Saugumas Didelės apkrovos be ribų lengviau panaudojamos piktavališkai (per dideli payload’ai, masinis skaitymas).

Tai normalu SaaS ir debesų ERP — ne klaida dizaine, o sąmoninga apsauga ir planavimas.

2. Vykdymo laiko limitai („timeout“)

Kas vyksta: užklausa prasideda serveryje; jei logika ar DB trunka ilgiau nei leidžia sluoksnis, ryšys nutraukiamas ir klientas mato timeout arba atitinkamą klaidos kodą.

Kur tai pasimato

  • Viešasis REST API — gide fiksuota: atsakymo laikas iki apie 5 min., ilgiau gali būti Read TimeOut (§6).
  • Naršyklė / tarpinis sluoksnis — dažnai griežtesni limitai nei 5 min (pvz. balansuotojas, CDN).
  • GraphQL — schemoje aprašyti klaidų tipai, pvz. DEADLINE_EXCEEDED (terminas baigėsi iki operacijos pabaigos).

Kodėl konsultantui svarbu: klientas „eksportuoja viską už metus“ vienoje sinchroninėje užklausoje — reikia tikėtis timeout arba perkelti į foninę užduotį (žr. asinchroninį eksportą).

3. Duomenų kiekio ir apdorojimo ribos

Kas vyksta: ne tik „kiek sekundžių skaičiuojame“, bet ir kiek įrašų traukiame, kiek MB siunčiame, kiek atminties užima vienas atsakas serveryje.

Pavyzdžiai iš dokumentacijos

  • GET sąrašai (REST) — iki 100 įrašų vienoje užklausoje; daugiau — puslapiavimas (gidas §6).
  • POST / PUT — payload iki 5 MB (tas pats šaltinis).
  • Ataskaitos / eksportas — didelis duomenų kiekis dažnai eina per Data Export ar panašų kelią su užduotimi ir failu, o ne per vieną trumpą HTTP atsaką.

Produkto diagrama (RAW → Reporting / Automation / Data Export / BI): konkretūs eilučių ir laiko rėmai pagal kelią — rivile-erp-duomenu-istraukimas-keliai-ribos.html.

„Apdorojimo limitas“ praktikoje gali reikšti: per didelis rezultatų rinkinys scenarijuje, per daug iteracijų, arba vidinės kvotos (automatikai stebimi resursai).

4. Automatizavimai ir eilės

Užduotys skirstomos į atskiras eiles pagal rūšį (Automation, Email Template, Reporting), kiekviena eilė turi prioritetų poskirsnius ir procesorius — tarp skirtingų eilių vykdymas gali būti lygiagretus, vienoje eilėje su vienu procesoriumi užduotys eina nuosekliai (konceptas §9). Bendras tikslas — ribotas lygiagretumas ir sąžiningumas, kad vienas sunkus scenarijus neužgožtų visko.

Pasekmė atstovui: ilgas ar dažnas scenarijus gali laukti eilėje, vykti ilgiau piko metu arba būti stabdomas pagal politiką — tai reikia įvardyti diegiant ir stebint vykdymo žurnalą / auditą.

5. Kodėl UI kartais „greitas“, o API ar eksportas — ne?

  • Ekranas dažnai rodo filtruotą nedidelį fragmentą (puslapius, lenteles).
  • Integracija be puslapiavimo bando paimti viską iš karto → ribos ir laikas.
  • Ataskaita už visą istoriją — skaičiavimas ir serializacija gali būti kelių minučių klasė; todėl naudojamas asinchroninis modelis (užduotis + failas).

6. Ką sakyti klientui (šablonas)

  1. Dideli kiekiai — naudoti puslapiavimą, filtrus pagal laiką, dalinti užduotis (mėnesiai, padaliniai).
  2. Ilgi procesai — foninės užduotys, el. pašto pranešimas, atsisiuntimas iš vartotojo užduočių — ne viena begalinė naršyklės užklausa.
  3. Integracijos — planuoti paketus, ne „vienas milijonas eilučių per vieną POST“, jei dokumentacija tai draudžia dydžiu ar praktika.
  4. Pikas — tuo pačiu metu daug vartotojų ir batch darbų gali padidinti laukimo laiką eilėse — tai debesų ERP norma.

7. Mokymų santrauka (1 skaidrė)

Tema Žinutė
Timeout Užklausa turi „termą“ — ilgos operacijos turi eiti per foną arba skaidyti.
Kiekio ribos 100 / 5 MB / puslapiavimas — ne patogumas, o stabilumas ir sąžiningumas.
Eilės Automatizavimai konkuruoja dėl resursų — prioritetai ir planavimas.
Eksportas Artemis / Data Mobility / failas — sąmoningas atsakas į didelį tūrį.

Jei Rivile vėliau pateiks tikslų papildomą dokumentą (pvz. tik organizacijai skirtos kvotos), šį failą verta papildyti konkrečiais skaičiais ir nuoroda.