Kombiniranje Delphi Desktopa i web-portala: arhitektura, sučelja i modernizacija bez prekida

U mnogim tvrtkama se tijekom godina središnja „stručna kontrolna točka“ razvila kao Delphi-desktop aplikacija: VCL-klijent, duboko procesno znanje, brzo unos podataka, tiskanje i reporting, specijalizirani hardver i često izravan pristup bazi podataka unutar LAN-a. Istovremeno rastu očekivanja za self-service i eksternu suradnju: klijenti žele provjeravati statuse narudžbi, razmjenjivati dokumente ili podnositi reklamacije – bez VPN-a, bez desktop roll-outa i bez lokalnih instalacija.

Delphi Desktop i web-portali u kombinaciji u praksi znači povezati ta dva svijeta tako da su operacije, sigurnost i konzistencija podataka pod kontrolom. Ključno nije „preslikavanje“ formi u pregledniku, nego arhitektura koja jasno odvaja procese, prava i tokove podataka te omogućuje oboma frontendima da rade prema zajedničkim pravilima. Dobit je put modernizacije bez Big-Bang pristupa: desktop ostaje produktivan dok web-portal kontrolirano raste.

Ovaj članak je namijenjen IT-u, administratorima i tehnički odgovornim projektantima. Fokus je na utjecajima na rad, administraciju, sučelja, sigurnost, pohranu podataka i migraciju – manje na detalje frameworka. Dobit ćete praktične uzorke, kriterije za odluku i tipične zamke s mjerama protiv.

Zašto je „Portal umjesto Desktopa“ rijetko realno

U B2B okruženjima postoji mnogo razloga zašto desktop-klijent i dalje ima smisla. Administratori to često doživljavaju vrlo konkretno: portal je idealan za distribuirane korisnike, ali određeni zadaci su u desktopu i dalje učinkovitiji ili čak jedino izvedivi.

Snažne strane desktopa koje znače u praksi

• Kompleksni unos podataka s vrlo gustom strukturom formi, upravljanjem putem tipkovnice, velikim tabličnim prikazima i brzim prebacivanjima među zapisima.
• Periferija i lokalne integracije poput pisača etiketa, skenera, serijskih uređaja ili specijalnih Windows-komponenti.
• LAN-bliska izvedba kad se obrađuju velike količine podataka ili kad proces zahtijeva izuzetno nisku latenciju.
• Ugrađeni radni tokovi s mnogo izuzetaka, gdje 1:1 port u portal nosi visoki rizik.

Snažne strane portala koje zadovoljavaju nove zahtjeve

• Vanjski pristup za klijente, dobavljače ili partnere bez potrebe za razmještanjem klijenta.
• Centralna upravljivost (verzije, značajke, prava) s jasnom vanjskom granicom.
• Neovisnost o uređaju (preglednik, mobilna upotreba) za terenski tim i upravljanje.
• Ciljano otvaranje procesa poput provjere statusa, uploadova, odobrenja ili ticket-procesa.

U kombinaciji leži korist: desktop ostaje alat za napredne interne uloge, portal postaje kontrolirani pristup za eksterne korisničke skupine. Kako se to ne bi raslo u dvije paralelne „istine“, potreban je povezujući servisni sloj.

Kada kombinirate Delphi Desktop i web-portale: tri ciljane arhitekture

Pri odluci o arhitekturi radi se prije svega o odgovornostima: gdje leže poslovna pravila? Tko smije mijenjati podatke? Koji sloj je „Single Source of Truth“ (određujući izvor pravila i stanja)? Za tehničke donositelje odluka važno je: izbor ima izravan utjecaj na operacije, otklanjanje grešaka, release-management i sigurnost.

Varijanta A: Portal kao dopuna preko REST-API-ja, desktop ostaje vodeći

Portal pokriva odabrane use-caseove, tipično „čitati i pokrenuti“: statusi, dokumenti, odobrenja, jednostavni unosi. Za to se uvodi Delphi REST-API ili zaseban REST-server. Desktop-aplikacija u početku može i dalje pristupati bazi izravno.

Operativna prednost: brz start, male intervencije u desktopu, pogodno za prvi portalni Mehrwert.

Rizična točka: postoje dva puta podataka (Desktop → DB izravno, Portal → API). Ako su poslovna pravila implementirana samo u desktopu, nastaju nekonzistentnosti. Protumjera je: započeti s portalnim funkcijama tamo gdje su pravila jednostavna i mogu se serverski reproducirati (npr. dostupnost dokumenata, provjera statusa, definirane akcije odobrenja).

Varijanta B: Service-kern kao zajednički procesni sloj (preporučeno kod paralelnog rada)

Ovdje postupno premještate poslovnu logiku iz desktopa u servise. Desktop i portal koriste iste endpoint-e. Desktop postaje više Rich Client (UI, lokalne integracije), dok pravila i validacije žive serverski.

Operativna prednost: centralno mjesto za prava, audit, logiku statusa i validacije; jednako ponašanje na svim front-endovima.

Napor: veći na početku, jer je potrebno jasno planirati standarde za API, formate pogrešaka, verzioniranje, monitoring i deployment. To smanjuje kasniji napor jer ima manje zasebnih rješenja.

Varijanta C: Portal vodi, desktop ostaje kao specijalizirani klijent

Ova varijanta ima smisla ako je cilj da preglednik postane standardni pristup (npr. snažno distribuirana organizacija), dok desktop ostaje za određene uloge sa specijalnim hardverom ili za brze ulaze podataka. Service-kern mora u tom slučaju biti posebno stabilan i skalabilan.

Layer-3 arhitektura kao razumljiva smjernica

Neovisno o varijanti pomaže Layer-3 arhitektura: (1) prezentacija (Desktop/Portal), (2) aplikacijski i domeni sloj (use-caseovi, pravila), (3) infrastruktura (baza podataka, pohrana datoteka, messaging, eksterni sustavi). Administratorima je to važno jer se granice operacija razbistre: što je „problem frontenda“, što je „problem servisa“, a što leži u bazi ili storage-u? Ta separacija skraćuje otklanjanje grešaka i smanjuje nuspojave pri deploy-ima.

Praktična veza: kako desktop i portal dijele isti proces

Najveći izazov rijetko je „izgraditi portal“, nego pitanje: kako desktop i portal podijele odgovornosti u istom procesu bez dupliciranja pravila? Tri obrasca su u praksi osobito relevantna.

1) Use-Case-API-ji umjesto tabličnih ili CRUD-API-ja

Česta slijepa ulica je API koji samo reflektira tablice baze („Create/Read/Update/Delete“). Tada se pravila moraju u portalu ponovno implementirati, a desktop ostaje sa svojim pravilima. Bolje su Use-Case-API-ji: endpointi koji opisuju poslovne akcije poput „kreiraj reklamaciju“, „odobri narudžbu“, „upload dokumenta“, „potvrdi status dostave“.

U radu je efekt opipljiv: validacije se vrše serverski, poruke o pogreškama su reproducibilne, i oba klijenta (desktop i portal) pokreću isti tijek preko iste logike.

2) Upravljati konfliktima i ponavljanjima

S dolaskom portala raste vjerojatnost paralelnih promjena i ponovljenih zahtjeva (npr. zbog timeouta, retry-eva ili dvostrukog klika korisnika). Tri koncepta pomažu bez uvođenja „stalne blokade“:

• Idempotentnost: kritične akcije su dizajnirane tako da ponavljanje daje isti učinak i ništa se ne izvršava dvaput. U praksi se to često postiže jedinstvenim identifikatorom zahtjeva (Idempotency Key).
• Optimistic Concurrency: zapis nosi informaciju o verziji (npr. „Row Version“). Prilikom izmjena servis provjerava odgovara li verzija i uredno vraća konflikte.
• Kratke transakcije: umjesto „sve zaključati“, pisanja se drže kratkima. Duži poslovi (npr. exporti, paketni reporti) se izvode asinkrono.

Za tehničke donositelje odluka važno je: ti mehanizmi smanjuju opterećenje podrške jer su tipični incidenti („dogodilo se dvaput“, „moja promjena je nestala“) znatno rjeđi.

3) Jasno modeliranje stanja i prijenosa

Ako desktop obrađuje kompleksne slučajeve, a portal „samo“ podnosi zahtjeve ili predfaze, trebate definirane prijelaze stanja. Praktičan raspored je: portal stvara ili dopunjava zapise u jasno ograničenim statusima (npr. „predano“), desktop rješava specijalne slučajeve, a service-kern odlučuje i bilježi promjene statusa. Tako sprječavate da portal-klijent posredno „pokvari“ procese konfiguriranjem neodgovarajućih stanja.

Podaci i dokumenti: često podcijenjeno područje integracije

Gotovo svaki portal donosi rad s datotekama: uploadi, dokazi, otpremnice, slike, PDF-izlazi. Za administratore je to ključna tema jer utječe na backup, prava pristupa, provjeru virusa, troškove pohrane i performanse.

Gdje pohraniti datoteke: baza podataka, file-share ili objektni storage?

Postoje tri uobičajene opcije pohrane, koje svaka impliciraju drugačiju operativnu realnost:

• Baza podataka (BLOB): dobra je ako transakcije moraju biti strogo povezane i ako backup/restore treba biti sve-u-jednom paket. Nedostaci su često veće baze podataka i dulji backup prozori.
• Filesystem/Share: tipično On-Prem, dobro se uklapa u postojeće backup koncepte. Važno je jasno definirati prava pristupa i imati API-sloj koji kontrolira pristup.
• Objekt-Storage: smislen pri skaliranju, pravilima životnog ciklusa ili kad se vanjski pristupi tehnički žele uredno kapsulirati. Zahtijeva svjestan model ključeva i prava.

Neovisno o mjestu pohrane vrijedi: portal ne bi trebao datoteke „direktno“ učitavati sa share-a. Bolje je kontrolirani download preko servisnih endpointa s provjerom prava, protokoliranjem i opcionalnim privremenim URL-om za preuzimanje.

PDF-ovi i reporti: serverska generacija umjesto dupliciranja

Delphi-desktop aplikacije često imaju razvijene tokove za ispis i reporting. Portali često trebaju iste sadržaje kao PDF. Umjesto održavanja dvije implementacije, isplati se centralizirana generacija dokumenata u service-kernu: predlošci, verzioniranje i format izlaza se nalaze serverski; desktop i portal konzumiraju rezultat. Za operacije to donosi jasne prednosti: reproducibilni izlazi, jedinstvena pohrana i manje ovisnosti o desktop-instalacijama.

REST-server i servisi: Delphi, C# ili mješovita arhitektura

Pri odluci „Delphi ili C#“ za tvrtke je manje stvar ideologije, a više timske sposobnosti, operativnog okruženja i održivosti. U mnogim okruženjima realistična je mješovita arhitektura, pod uvjetom da su odgovornosti jasno razdvojene.

Delphi kao servisna platforma: smisleno ako postoji poslovna logika

Ako su poslovna logika i pristup podacima već dobro implementirani u Delphi, Delphi-bazirani REST-server može biti učinkovit. Administratorima i odlučiteljima važno je: rad servera nije „desktop koji stalno radi“. Produktivan servis zahtijeva jasnu konfiguraciju, uredne timeoute, strukturirane logove, health-checkove i reproducibilan deployment.

Također bi se pristup podacima trebao modernizirati ako su još u igri stari driveri ili BDE. BDE-Ablösung i prelazak na moderne pristupe smanjuju smetnje u radu i olakšavaju deployment jer je manje legacy-komponenata za instalirati i održavati.

C# servisi u portalnom ekosustavu: često zbog hostinga i identity

Ako portal nastaje u .NET-dominiranoj okolini, C# servisi su često logični izbor – ne najmanje zbog integracije identity-ja, postojećih operativnih standarda i hostinga iza Microsoft IIS ili u kontejneriziranim platformama. Ključno je izbjeći dvostruke implementacije: ili poslovna logika ostaje u Delphi-servisima, a C# preuzima edge-teme (npr. portal-specifičnu orkestraciju), ili se planira kontrolirana migracija logike u .NET s jasnim granicama domene.

API-Gateway: element reda, ali nije nužnost

API-Gateway može koncentrirati centralne funkcije (routing, rate-limits, logging, autentikacija). Za manje početne arhitekture često je dovoljna konzistentna API s jedinstvenim standardima. Međutim, čim postoji više servisa i skupina korisnika, gateway pomaže stabilizirati vanjsku granicu i centralno provoditi politike.

Autentikacija i prava: od internog desktopa prema eksternom portalu

S portalom se mijenja krajolik korisnika: uz interne korisnike pojavljuju se eksterni računi, uloge i najmoprimci. To stvara zahtjeve za identity, autorizaciju i auditabilnost. Administratorima je to važno jer su sustavi identiteta i modeli uloga kasnije teški za promjenu.

SSO sa SAML 2.0 ili OIDC: manje administracije, bolja kontrola

U B2B okruženjima SAML 2.0 (single sign-on preko Identity Providera) je često korišten jer tvrtke žele iskoristiti postojeće identitete. OIDC (OpenID Connect) je također u upotrebi, posebno na modernijim platformama. Klasični korisnik/lozinka logini su mogući, ali znače dodatni rad na politici lozinki, MFA, procesima resetiranja i podršci.

Važno za arhitekturu: autentikaciju (tko si?) i autorizaciju (što smiješ?) treba provjeravati serverski – ne u portal-frontend-u.

Multitenancy i model uloga: ne dodavati „kasnije“

Korisnički portal obično zahtijeva razdvajanje najmoprimaca: klijent vidi samo svoje podatke. To treba modelirati u service-kernu, idealno preko:

• Claims u tokenu (npr. Tenant-ID, uloge, referenca ugovora) kako bi servisi mogli donositi odluke.
• Provjere na razini zapisa (Row-Level-Checks u poslovnoj logici), a ne samo „sakrij izbornik“.
• Audit-trail za važne akcije (tko, što, kada), plus korelacija preko Request-ID-a radi analize grešaka.

Desktop može – ako je poželjno – također raditi s tokenima prema istom identity-stacku. To smanjuje posebne puteve i olakšava praćenje promjena, osobito kada portal i desktop rade na istom zapisu.

Modernizacija pristupa podacima: FireDAC, PostgreSQL i kontrolirani podatkovni putevi

Mnoge Delphi-desktop solucije povijesno su rasle s izravnim pristupom bazi. Kad se doda portal, to postaje arhitektonsko pitanje: putovi podataka moraju biti kontrolirani, validacije moraju biti centralne, i performanse moraju ostati stabilne pod paralelnim opterećenjem.

FireDAC kao osnova za održiv pristup podacima

BDE-Ablösung s native povezivanjem je u Delphi okruženjima uobičajeni standard za pristup modernim bazama. Važno je manje sama komponenta, a više ujednačavanje: parametrizirani upiti, čiste transakcijske granice, jedinstveno rukovanje greškama i mjerljiva vremena izvođenja. Za operativu je važno da su timeoute i potrošnja resursa predvidljivi i da se problemi mogu pročitati iz logova i monitoringa.

PostgreSQL s Delphi: dobro kontrolirano uz uredan tip-mapping i koncept migracije

PostgreSQL s Delphi je robustan ako se pažljivo rukuju mapiranja tipova (npr. UUID, vremenski žigovi, JSON-polja), indeksi i migracije sheme. Portali posebno generiraju mnoge filtrirane liste; filteri, paging i sortiranje trebaju se raditi serverski kako se ne bi prenosile velike količine podataka nepotrebno. To smanjuje opterećenje i poboljšava UX bez usporavanja desktopa.

Operacije, deployment i monitoring: postići portalnu zrelost za Delphi backende

Portal je obično stalno dostupan i time operativno intenzivniji od čistog desktopa. Administratorima je to područje gdje se dobra arhitektura odmah isplati: kroz reproducibilne deploymente, jasnu observability (logovi/metrike) i definirane prozore održavanja.

Windows-service ili Linux-service: ključno je operativni model

Delphi-servis se može pokretati kao Windows- i Linux-servis ili kao Linux-daemon. Važniji od operativnog sustava su standardi koji čine rad stabilnim:

• Health-Checks za monitoring i load balancer (npr. „servis radi“ i „baza dostupna“).
• Strukturirano logiranje (uključujući Request-ID, korisnik/tenant, trajanje, statusne kodove) kako bi se slučajevi podrške mogli reproducirati.
• Konfiguracija bez ponovnog gradnja (npr. varijable okoline, centralne konfiguracijske datoteke) da deploy-ovi budu automatizirani.
• Mogućnost rollbacka kroz jasne verzije i migracijski sigurne promjene u bazi.

Profil opterećenja: portal je „mnogi kratki zahtjevi“ umjesto „nekoliko dugih sesija“

Korištenje desktopa često generira dulje radne faze po korisniku, dok portali generiraju mnogo kratkih, paralelnih zahtjeva. Tipične tehničke mjere su:

• konzistentni paging, serverski filteri i ograničene veličine odgovora
• cacheiranje za master-podatke i rijetke upite
• asinkroni poslovi za dugačke zadatke (exporti, paketni reportovi)
• rate-limiti i zaštitni mehanizmi protiv zloupotrebe

Za odlučivanje je ključno: performanse nisu „fino podešavanje na kraju“, nego dio definicije API-ja (veličine odgovora, time-outi, obrada u pozadini).

Modernizacija bez Big-Bang: pouzdani put u pet koraka

Potpuni rebuild rijetko je potreban i često je rizičan jer je procesno znanje ugrađeno u Delphi-klijent. Dokazano je postupanje u fazama gdje je svaka razina produktivno upotrebljiva i ne ugrožava rad.

1) Inventura: procesi, vlasništvo podataka, integracije

Ne počinjite od formi, nego od use-caseova: koji se tijekovi trebaju dovesti u portal? Koje podatke eksterni korisnik smije vidjeti ili mijenjati? Koja su sučelja prema ERP-u, DMS-u ili CRM-u? Iz toga nastaje prioritizirana lista API-ja koja donosi stvarnu vrijednost.

2) Definiranje servisnih osnova: auth, format grešaka, logiranje, verzioniranje

Ta osnova odlučuje o kasnijoj održivosti. Dogovorite rano standarde za autentikaciju/autorizaciju, konzistentan format pogrešaka, korelaciju zahtjeva, verzioniranje API-ja i telemetriju. To smanjuje trenje među timom portala, backend timom i operacijama.

3) Isporuka prve portalne trase end-to-end

Odaberite proces s jasnom granicom (npr. dokumentno područje ili provjera statusa). Važno je da cijeli lanac funkcionira: login, provjera prava, API, UI, logiranje, monitoring, operacija. Organizacija tako rano vidi koji standardi funkcioniraju u praksi.

4) Ciljano povezivanje desktopa: kritične staze pisanja preko servisa

Kad su servisi stabilni, premjestite odabrane desktop-funkcije: posebno promjene statusa, odobrenja ili centralne validacije. Desktop ostaje brz, ali pravila postaju dosljednija i izravan zapis u bazu se postupno smanjuje.

5) Konsolidacija: uklanjanje dvostrukih pravila i posebnih puteva

Inače će s vremenom nastati „dva sustava“. Planirajte redovite konsolidacije: koja pravila postoje dvaput? Gdje portal može koristiti servis desktopa? Koje se izvještaje treba centralno generirati? Cilj je upravljiva platforma, ne dogma.

Tipične zamke iz operativne perspektive – i kako ih izbjeći

Pravila se u portalu ponovno grade

To vodi do odstupanja i slučajeva podrške. Protumjera: Use-Case-API-ji s serverskim validacijama, jasnim povratima grešaka i, gdje je moguće, zajedničkim poslovnim testnim scenarijima.

Neprecizno vlasništvo podataka između desktopa i portala

Ako oba klijenta smiju „sve“ mijenjati, nastaju konflikti. Protumjera: model statusa, definirane odgovornosti i Optimistic Concurrency za konkurentne promjene.

Sigurnost kao naknadni dodatak

Posebno za korisničke portale SSO, najmoprimčevske provjere, sigurno preuzimanje datoteka i audit trebaju biti planirani od početka. Naknadno to postaje skuplje i povećava rizik sigurnosnih propusta.

Nedostatak transparencije u operacijama

Bez Request-ID-eva, strukturiranih logova i health-checkova otklanjanje grešaka postaje detektivski posao. Protumjera: observability kao obvezan dio prvih servisnih izdanja.

Zaključak: Service-kern povezuje snagu desktopa s dosegom portala

Kombinacija Delphi-desktopa i web-portala u mnogim je tvrtkama najrealističniji put za očuvanje ključnih procesa uz omogućavanje vanjske suradnje. Ključno je da ne upravljate dvjema odvojenim sferama, nego da izgradite povezujući service-kern: Use-Case-API-ji, čista prava, reproducibilna stanja, kontrolirani tokovi podataka i operativni model s logiranjem, monitoringom i predvidljivim deploy-ima.

Tako nastaje modernizacija s međuciljevima: desktop ostaje produktivan, portal rano donosi vrijednost, i arhitektura postaje korak po korak konzistentnija i održivija.

U stručnom kontekstu i Delphi Modernisierung igra važnu ulogu kad integracije, tokovi podataka i daljnji razvoj trebaju raditi usklađeno.

Projekt ili plan modernizacije s Net-Base raspravite.