REST serverio kūrimas su Delphi: architektūra, saugumas ir eksploatacija praktikoje

Kas nori sukurti REST-serverį su Delphi, įmonėse retai siekia tik paties tikslo. Dažniausiai kalbama apie patikimas sąsajas tarp susiformavusių sistemų, portalų, paslaugų ir duomenų bazių – su aiškiais reikalavimais eksploatacijai, saugumui ir prižiūrimui. Svarbu ne tiek, kaip greitai atsako pirmasis galinis taškas, kiek ar paslauga išlieka stabili kasdieniame režime: aiškiai atsekami klaidų scenarijai, kontroliuojamos duomenų prieigos, tvarkinga autentifikacija, aiškios atsakomybės architektūroje ir diegimo modelis, tinkantis Windows- ir Linux-aplinkoms.

Delphi daugelyje organizacijų yra pragmatiškas pasirinkimas: esama domeninė logika gali būti naudojama toliau, našumas paprastai yra pakankamas, ir egzistuoja keli keliai, kaip įgyvendinti HTTP pagrindu veikiančias API. Praktikoje variantai skiriasi ne tiek „ar galima padaryti REST“, kiek skaidrumu ir eksploatacija: kaip nuosekliai įgyvendinami logavimas, timeouts, reverse-proxy taisyklės, versijavimas, OpenAPI dokumentacija ir saugumo mechanizmai?

Šis straipsnis susistemina svarbiausius Delphi požiūrius ir parodo, kam IT vadovai, administratoriai ir techniniai projekto atsakingieji turėtų skirti dėmesį: nuo API dizaino per saugumą ir BDE-Ablösung su gimtąja jungtimi-duomenų prieigą iki Observability (logai, metrikos, tracing) ir diegimo kaip Windows- arba Windows- ir Linux-servisai. Tikslas – tvirta pagrindas integracijoms su ERP, DMS, CRM ar klientų portalais, nekeliant į centrą framework-internų.

Kada REST-serveris su Delphi ypač prasmingas

Delphi-REST backendas dažnai yra prasmingas, kai Delphi jau yra įsitvirtinęs įmonėje arba kai domeninė logika ir duomenų prieigos iš esamų taikomųjų sprendimų turi būti panaudotos toliau. Tipinės B2B situacijos:

• Sistemos pritaikymas API: VCL taikomoji programa arba klientų-serverių branduolys gauna REST sluoksnį, kad portalai, išorinės sistemos ar vidiniai servisai galėtų prieiti standartizuotai.
• Integracija ir atskyrimas: keli vartotojai (darbalaukis, žiniatinklio portalas, batch, partneriai) turi naudoti tuos pačius verslo procesus be tiesioginių DB prieigų ar failų sąsajų.
• Modernizavimas etapais: pirmiausia įdiegti stabilų API, vėliau palaipsniui keisti UI, modulius arba duomenų bazę. API tampa kontroliuojama riba ir sumažina šalutinį poveikį.
• Eksploatavimas ir saugumas: HTTP-API gerai veikia už reverse proxy, jas galima centralizuotai autentifikuoti ir įtraukti į monitoring staktus.

Svarbu tikėtis realistiškai: REST yra integracijos sąsaja, o ne pakaitalas domeninei nuoseklumui. Pradedant be aiškaus domeno modelio, apibrėžtų transakcijų ribų ar aiškios duomenų atsakomybės, greitai sukuriama API, kuri yra pasiekiama, bet ilgainiui brangi palaikyti ir aptarnauti.

REST-serverio kūrimas su Delphi: variantų apžvalga

Delphi siūlo kelis būdus sukurti REST servisą. Sprendimų priėmėjams svarbiau ne „kas yra moderniausia“, o kaip gerai tai atitinka komandos struktūrą, valdymo modelį, gyvavimo trukmę ir atitikties reikalavimus.

Delphi WebBroker: santūrus, skaidrus, gerai kontroliuojamas

WebBroker yra įtvirtintas Delphi karkasas HTTP taikomosioms programoms. Jis yra arti protokolo (Request/Response), todėl gerai įžvelgiamas ir patrauklus daugeliui B2B scenarijų, kur reikalinga kontroliuojama klaidų tvarka, tvarkingas header valdymas ir suprantama stack struktūra. WebBroker paprastai gerai veikia už reverse proxy, kuriame terminizuojamas TLS ir įgyvendinamos centralizuotos saugumo taisyklės.

Praktinė išvada: daugelį komforto funkcijų (routing konvencijos, middleware grandinės, OpenAPI palaikymas) reikės struktūruotai papildyti. Tai nėra trūkumas, jei architektūros standartai ir taip yra prioritetas.

Delphi Horse: routing ir middleware aiškiems API standartams

Delphi Horse yra lengvas sprendimas, grindžiamas suprantamu routing’u ir middleware principu. Middleware čia reiškia: pakartotinai naudojamus apdorojimo žingsnius „apie“ galinį tašką, pvz., autentifikaciją, logavimą, rate limits arba request validaciją. Daugeliui komandų tai produktyvus požiūris, nes standartus galima priversti veikti centralizuotai.

Eksploatacijos požiūriu svarbu: nuo ankstyvo etapo apibrėžkite vienodą klaidų formatą, timeouts, maksimalų request dydį ir logavimo standartą. Be šių nuostatų sistema išliks funkcionuojanti, bet palaikymas ir plėtra taps neadekvačiai sunki.

RAD Server: platforminis požiūris su integruotais komponentais

RAD Server (anksčiau EMS) labiau orientuotas į platforminį požiūrį, turėdamas integruotas funkcijas, pvz., naudotojų valdymą ir kitus blokelius. Tai gali būti tinkama, kai keli klientai naudoja bendrą backend’ą ir platformos funkcijos yra tikslingai naudojamos. Tačiau grynoms integracijos API dažnai svarbesnė skaidrumas, mažos priklausomybės ir santūrus eksploatacijos modelis, tad RAD Server ne visada yra geriausias pasirinkimas.

DataSnap: esamų diegimų realistiškas įvertinimas

DataSnap istoriškai yra daugelyje Delphi kraštovaizdžių ir gali teikti HTTP/REST tipo galinius taškus. Naujiems projektams verta patikrinti, ar jis atitinka planuotą API stilių, autentifikaciją (pvz., JWT), OpenAPI/Swagger ir modernius eksploatacijos reikalavimus. Dažnai pragmatiškas kelias yra: naudoti esamą logiką, bet įdiegiant išorinį, aiškiai apibrėžtą REST API sluoksnį, kuris užtikrina standartus saugumui, logavimui ir versijavimui.

Architektūra, kuri palaiko eksploataciją ir priežiūrą

Dažna klaida REST projektuose yra „handleris atlieka viską“: HTTP parametrai nuskaitomi, tiesiogiai konstruktuojami SQL, įgyvendinamos verslo taisyklės ir tuo pačiu metu dar vykdomas logavimas. Tai iš pradžių atrodo greita, bet veda prie sunkiai testuojamo kodo ir nestabilių pakeitimų.

Įmoninėse aplinkose pasiteisina aiškus sluoksniavimas. Praktinė, plačiai taikoma struktūra yra Layer-3-architektūra (trijų sluoksnių), kuri atskiria atsakomybės sritis:

Transporto sluoksnis: HTTP, autentifikacija, validacija, atsakymo formatas

Čia priimamas request, atliekama pradinė validacija ir formuojamas nuoseklus atsakymo formatas. Į šį sluoksnį taip pat priskiriama autentifikacija ir autorizacija (kas ir ką gali atlikti) bei techninės taisyklės, pvz., request limitai, CORS arba Correlation-ID suteikimas (unikalūs ID kiekvienam užklausai stebėsenai).

Domenų sluoksnis: verslo use-case’ai, o ne endpoint logika

Domenas kapsuliuoja tokius verslo procesus kaip „sukurti užsakymą“, „pakeisti būseną“ arba „sujungti dokumentą“. Svarbu, kad ši logika būtų kuo mažiau priklausoma nuo HTTP karkaso. Tada ta pati domeno logika gali būti naudojama ir iš Windows- ir Linux-servisų, demono ar batch proceso, be logikos dublikatų.

Persistencija ir integracija: FireDAC, duomenų bazė, ERP/DMS/SMTP

Šis sluoksnis sujungia prieigas prie DB ir išorinių sistemų. Delphi kontekste įprastas duomenų prieigos sluoksnis yra BDE-Ablosung mit nativer Anbindung, skirtas tvarkingam PostgreSQL, SQL Server, MariaDB/MySQL ar Firebird prijungimui. Svarbu ne tik „naudoti FireDAC“, bet ir nustatyti privalomas taisykles: connection handling, transakcijų ribas, timeout’us, parametrų rišimą, techninių klaidų vertimą į API klaidų kodus ir vienodą retry strategiją ten, kur tai prasminga domeniškai.

API dizainas: stabilus per metus, ne tik iki Go-live

B2B aplinkoje API yra ilgalaikė prižiūrima sąsaja. Pagrindinis terminas yra suderinamumas: vartotojai remiasi laukais, statuskodais ir semantika. Kuo aiškiau apibrėžsite šias taisykles, tuo mažiau darbo kils integracijoms, palaikymui ir leidimams.

Ištekliai ir keliai: nuoseklumas svarbiau už kūrybiškumą

Stabilios API dažniausiai yra resursų orientuotos: „/customers“, „/orders/123“, „/orders/123/items“. Procesų veiksmai gali būti atvaizduojami kaip sub-resursai arba pagrįsti veiksmo endpoint’ai, pvz., „/orders/123/cancel“, kai grynas CRUD modelis netinka domenui. Esminė sąlyga – vienoda konvencija, dokumentuota ir naudojama visos komandos.

HTTP metodai ir statuskodai: aiškūs signalai vartotojams

API yra lengviau integruoti, jei ji naudoja laukiamą HTTP semantiką: GET skaitymui, POST kūrimui, PUT/PATCH keitimams, DELETE šalinimui. Taip pat svarbu: nuoseklus klaidų elgesys. Eksploatacijos požiūriu naudingas standartizuotas klaidų objektas su:

• HTTP statusu (pvz. 400, 401, 403, 404, 409, 422, 500)
• stabiliu klaidos kodu (mašininio skaitymo, dokumentuotas)
• Correlation-ID (greitam priskyrimui loguose)
• neprivalomais detalėmis (pvz. laukų klaidos validacijoje)

Dažna klaida – siųsti „200 OK“ su klaidos tekstu body. Tai apsunkina integracijas ir sukelia klaidžios kliento logikos poreikį.

Versijavimas ir suderinamas plėtimas

Versijavimas yra procesų ir komunikacijos klausimas, o ne vien techninis. Dažnai taikomi metodai – versijos URL (pvz. „/api/v1“) arba versijavimas per header’ius. Vis dėlto svarbiausia taisyklė daugelyje įmonių yra: plėsti suderinamai. Naujų laukų pridėjimas dažniausiai yra nekritinis. Laukų šalinimas arba reikšmės keitimas reikalauja naujos versijos ir aiškaus migracijos lango. Tai sumažina integracijų sutrikimus ir leidžia planuoti išleidimus.

Sauga: autentifikacija, autorizacija, atakų paviršiai

REST-servisas yra potencialus įsilaužimo taškas. Daugelis saugumo problemų kyla ne dėl trūkstamos šifravimo, o dėl smulkių klaidų: per plačios teisės, per ilgos tokenų galiojimo trukmės, neapsaugoti admin endpoint’ai, nekontroliuojamos CORS taisyklės arba logai, kuriuose yra jautrūs duomenys.

TLS ir Reverse Proxy: aiškios atsakomybės tinkle

Tipiniuose konfigūracijos modeliuose TLS terminizuojamas Reverse Proxy (pvz., Nginx, Apache arba Microsoft IIS kaip Reverse Proxy). Delphi servisas veikia vidiniame HTTP ir yra prieinamas tik iš vidinio tinklo. Svarbu turėti aiškias taisykles „X-Forwarded-For“ ir „X-Forwarded-Proto“, kad kliento IP ir protokolas būtų teisingai interpretuojami. Ši informacija yra reikšminga audito, rate limiting ir klaidų diagnostikos tikslais.

JWT, API-Keys ir SSO: kas praktiška

System-to-system integracijoms paplitę API-Keys arba client-credentials mechanizmai. Vartotojų prieigoms įmoninėje aplinkoje dažnai praktiški yra JWT (JSON Web Token) kartu su centralizuotu Identity Provider (pvz., OIDC). SSO kraštovaizdyje taip pat gali būti aktualus SAML 2.0 (standartas Single Sign-on, dažnai tarp portalo/gateway ir identity provider).

Nesvarbu, koks metodas pasirenkamas, reikėtų apibrėžti:

• raktų ir sertifikatų rotaciją (kaip keičiasi parašų raktai?)
• roles/scopes (kokios teisės reikalingos kuriems endpoint’ams?)
• nuomininkų izoliaciją (kaip patikimai užtikrinti tenant priskyrimą?)
• audito logavimą (kas, kada ir kokią veiklą inicijavo?)

Įvesties validacija, CORS ir Rate Limiting

Įvesties validacija turėtų vykti keliais lygiais: sintaksės (duomenų tipai, JSON struktūra), domeno lygmens (kintamųjų ribos, būsenų pereigos) ir saugumo (failų pavadinimai, keliai, header’iai). Naršyklės kliento atveju svarbus CORS (kokie origin ir header’ai leidžiami). CORS turi būti konfigūruojamas griežtai. Rate Limiting apsaugo nuo piktnaudžiavimo ir apkrovos piko; dažnai jis įgyvendinamas reverse proxy lygyje ir papildomas serverio pusės limitais (maksimalus body dydis, timeout’ai, ribota lygiagreti vykdymo talpa).

FireDAC ir DB prieiga: stabilumą užtikrina taisyklės

REST backenduose DB prieiga dažnai lemia latentę ir stabilumą. FireDAC suteikia technines galimybes, bet eksploatacijos saugumą užtikrina tvarkos taisyklės.

Connection handling ir lygiagretumas

Tipiška klaida – globalaus lygio bendrinama DB jungtis, kurią lygiagrečiai naudoja keli užklausos. REST-serveriuose su lygiagrečiu apdorojimu (threads/workeriai) turi būti aišku, kurie objektai yra thread-safe, o kurie ne. Praktikoje tai reiškia: valdyti jungtis ir query objektus priskiriant juos užklausai arba Unit-of-Work lygiui arba naudoti kontroliuojamą pooling’ą, priklausomai nuo serverio modelio. Tai mažina deadlock’us, epizodines klaidas ir sunkiai reprodukuojamus sutrikimus.

Transakcijos pagal use-case’us

Transakcijos turi būti domenuje: use-case nusprendžia, kas turi būti atlieka atominiu veiksmu. Dažnai „viena užklausa = viena transakcija“ yra prasminga, bet ne visada. Read-only endpoint’ai dažnai neturi reikalavimo atviros transakcijos, tuo tarpu rašančios operacijos gali reikalauti kelių lentelių nuoseklaus atnaujinimo. Integracijose su išorinėmis sistemomis (ERP, DMS, webhook’ai) paskirstytos transakcijos dažnai yra nerealaus dydžio; čia padeda aiški seka ir kompensacinė logika (kaip atstatomas dalinis pasiekimas?).

Timeout’ai, grįžtamojo slėgio valdymas ir kontroliuojamas gedimas

Be timeout’ų užklausos, thread’ai ir DB jungtys kaupiasi. Todėl nustatykite timeout’us HTTP ir DB lygiu. Papildomai svarbus yra grįžtamojo slėgio valdymas (Backpressure): ribokite lygiagretumą ir eilės ilgius, kad sistema apkrovos atveju kontroliuotai reaguotų su 503 (Service Unavailable), o ne visiškai nebeveiktų dėl išteklių išeikvojimo. Eksploatacijoje aiškus ir greitas klaidos vaizdas yra geriau nei kelių minučių užstrigimai.

Payload’ai, DTO ir ilgalaikis suderinamumas

JSON yra standartas, bet interoperabilumą lemia detalės: datos/laiko formatas, laiko zonos, null reikšmės, dešimtainės reikšmės atvaizdavimas, laukų pavadinimai ir encodingas. Nustatykite standartą (pvz., ISO-8601 UTC) ir taikykite jį nuosekliai.

DTOs vietoj tiesioginio DB struktūrų publikavimo

DTOs (Data Transfer Objects) yra API duomenų modeliai, optimizuoti mainams. Jų neturėtų tiesiogiai atspindėti duomenų bazės lentelės. Taip išvengsite, kad vidiniai schemos pakeitimai iš karto sulaužytų API. Be to, galite kontroliuoti, kurie vidiniai laukai nepateks į išorinę sąsają (pvz., flag’ai, audito stulpeliai) ir kaip vėliau atlikti vidinį refaktoringą be integracijų rizikos.

Apmąstyti idempotentiškumą ir retry mechanizmus

Įmonių tinkluose timeout’ai ir retry yra normalu. Apibrėžkite, kurios operacijos yra idempotentinės (kelis kartus atlikus – tas pats rezultatas) ir kaip išvengti dvigubų POST’ų, pvz., per Idempotency-Key tam tikroms rašančioms operacijoms. Tai sumažina dublikatų, nekonsistencijų ir support atvejų kiekį.

Dokumentacija ir testai: OpenAPI kaip bendras darbo pagrindas

API B2B sąlygomis retai naudojama tik vienos komandos. OpenAPI (Swagger) yra praktiška bendra kalba, nes specifikacijos gali būti automatizuojamos: klientų generavimas, mocking’as, contract test’ai ir skirtumų tikrinimas tarp versijų. Net jei Delphi stack’as visko negeneruoja automatiškai, prižiūrima specifikacija yra vertingas centrinis artefaktas.

Pragmatiškas testavimo aprėptis, mažinanti eksploatacijos kaštus

Praktinė testavimo struktūra REST servisams dažniausiai apima tris lygius:

• Unit testai domeno logikai (be HTTP, be DB)
• Integraciniai testai duomenų prieigai ir transakciniam elgesiui (su testine DB ir reproducinamais seed duomenimis)
• API/contract testai prieš veikiančią paslaugą (statuskodai, auth, klaidų formatas, versijavimas)

Administratoriams ir eksploatacijos komandoms svarbiausia: testai turi būti reproducibilūs ir nepriklausomi nuo vystytojų aplinkų. Kuo labiau testavimo aplinka atitinka tikrąjį diegimą, tuo mažesnė rizika netikėtumams atnaujinimų metu.

Diegimas ir eksploatavimas: Windows-service, Linux-service, konteineriai

REST-serveris praktiškai laikomas „paruoštas“, kai jį galima stabiliai eksploatuoti: start/stop elgsena, log-rotation, atnaujinimai, teisės, portų atidarymas, sertifikatai, monitoringas ir aiškios rollback galimybės.

Windows- ir Linux-servisai: patikrinti eksploatacijos modeliai

Windows aplinkoje dažnai natūralu veikti kaip Windows-servisas, nes egzistuoja mechanizmai start tipo, recovery, teisių ir monitoring atveju. Linux pasaulyje dažnai naudojamas systemd-servisas (systemd yra standartinis service manager), kuris kontroliuoja restart politikas, logavimo integraciją ir paleidimo seką. Abiem atvejais priešais servisą dedamas reverse proxy supaprastina TLS, header politiką, rate limits ir routing’ą.

Konteineriai: reproducibilu, bet tik su aiškia būsenos atskirtimi

Konteineriai gali vienodinti diegimus ir pagreitinti rollout’us. Reikalinga sąlyga – aiški valstybės atskirtis: DB išorinė, failai volum’ai, secret’ai per secret management. Be šios disciplinos susidaro sunkiai prižiūrimos mišrios būsenos, kurios pasireiškia sutrikimų ar atkūrimo scenarijuose.

Konfigūracija: atsekama, atskirta pagal aplinkas, be secret’ų repozitorijoje

Nuoseklus konfigūracijos modelis padeda: atskiros reikšmės Dev/Test/Prod, centralizuotas log-levelių apibrėžimas, DB prisijungimo duomenys, timeout’ai, leistini origin’ai ir token raktai. Jautri informacija neturi būti šaltinio kode. Audito ir eksploatacijos tikslais svarbu, kad konfigūracijos pakeitimai būtų atsekami ir galėtų būti valdomai išrullinti.

Observability: logai, metrikos ir tracing kaip eksploatacijos prielaida

Kai integracijos stringa, eksploatacijos komandai reikalingi atsakymai: kurie endpoint’ai paveikti, nuo kada, su kokiu klaidų dažniu ir kuri priklausomybė yra lėta? Be observability kiekvienas sutrikimas tampa rankine detektyvine užduotimi.

Struktūruotas logavimas ir Correlation-ID

Struktūruotas logavimas (Key/Value arba JSON) leidžia analizes per įrankius ir palengvina filtravimą pagal endpoint’ą, tenant’ą, klaidos kodą arba Correlation-ID. Kiekvienam užklausui turi būti priskirta Correlation-ID, kuri taip pat grąžinama atsakymo header’yje. Jautri informacija, pvz., slaptažodžiai, token’ai ar asmens duomenys neturi būti loguojami; padeda maskavimas, hashing’as arba specialūs debug log’ai izoliuotose aplinkose.

Metrikos talpai ir stabilumui

Praktiškai naudingos metrikos: requestų dažnis, latenčiai (pvz., p95/p99), klaidų dažnis pagal endpoint’ą, DB laikai, aktyvių workerių/threads skaičius, connection apkrova ir eilių ilgiai. Šios reikšmės yra pagrindas talpos planavimui ir padeda atpažinti lėtai kylantį problemas (trūksta indeksų, atsirado naujos priklausomybės, nepalankūs užklausų keliai).

Modernizavimo kelias: REST kaip stabili riba augantiems Delphi sistemoms

Daugelis Delphi kraštovaizdžių mato REST API ne kaip galutinį sprendimą, o kaip stabilumo ir modernizacijos komponentą. Patikrintas, mažos rizikos metodas yra etapinis:

1. Prioritizuoti use-case’us: kokios funkcijos turi būti prieinamos išorėje (pagrindiniai duomenys, būsenų pakeitimai, dokumentų prieiga, patvirtinimai)?
2. Nustatyti API standartus: auth, klaidų formatas, versijavimas, logavimas, timeout’ai, rate limits, OpenAPI.
3. Ištraukti domeną: struktūruoti domeninę logiką taip, kad ji nebūtų priklausoma nuo UI arba atskirų endpoint’ų.
4. Konsoliduoti duomenų prieigą: FireDAC taisyklės, transakcinė koncepcija, performance baseline’ai, užklausų politikos.
5. Perėjimas vartotojų palaipsniui: darbalaukis, portalai ir kiti servisai pradeda naudoti API; tiesioginės DB prieigos mažėja.

Rezultatas – sistema, kurią galima tobulinti etapais: modulius galima atnaujinti, nepriversdami atlikti nekontroliuojamų pakeitimų visuose klientuose.

Tipinės kliūtys B2B REST projektuose

Kelios klaidų kategorijos kartojasi ir yra lengvai išvengiamos taikant aiškias taisykles:

• Nenuoseklūs klaidų formatai: palaikymas ir integracija tampa nepagrįstai sudėtingi. Sprendimas: standartizuotas klaidų objektas su stabiliais klaidų kodais.
• Sauga palikta vėlesniam etapui: roles, tenant palaikymas ir auditas pridedami „vėliau“. Sprendimas: planuoti kaip bazinę struktūrą, o ne improvizuoti po vieną endpoint’ą.
• Jokių limitų: trūksta body-limitų, timeout’ų ir lygiagrečių vykdymų ribų, todėl apkrovos atvejais kyla sutrikimai. Sprendimas: reverse proxy kartu su server-side backpressure.
• Duomenų bazė per arti API: kiekvienas schemos pakeitimas sulaužo consumer’ių darbą. Sprendimas: DTOs ir aiškiai apibrėžti use-case’ai.
• Per maža observability: problemos nėra matuojamos. Sprendimas: Correlation-ID, struktūruoti logai, pagrindinės metrikos.

Išvados: REST su Delphi reiškia atsakomybę už sąsają ir eksploataciją

REST-serverio kūrimas su Delphi įmoninėse aplinkose būna tvariai sėkmingas, kai nuo pradžios kartu planuojama architektūra ir operacijos. Karkaso pasirinkimas (WebBroker, Horse, RAD Server arba migracijos kelias iš DataSnap) yra svarbus, bet ne pats lemiantis veiksnys. Esminį skirtumą daro aiškūs standartai API dizainui, autentifikacijai, klaidų tvarkymui, versijavimui, FireDAC duomenų prieigai, timeout’ams bei observability ir diegimui kaip Windows- arba Linux-serviso. Taip sąsaja tampa stabiliu integracijos komponentu, leidžiančiu modernizuoti, o ne blokuoti pokyčius.

Techniniame kontekste taip pat svarbios Delphi REST-API ir Delphi REST-API und REST-Server, kai integracijos, duomenų srautai ir tolimesnis vystymas turi veikti kartu tvarkingai.

Projektą ar modernizavimo užduotį aptarti su Net-Base.