Kombinovanje Delphi Desktopa i Web-portala: arhitektura, interfejsi i modernizacija bez prekida

U mnogim preduzećima je funkcionalni „upravljački centar“ tokom godina izrastao kao Delphi-desktop aplikacija: VCL-klijent, duboko procesno znanje, brzi unos podataka, tokovi za štampu i izvještavanje, specijalni hardver i često direktan pristup bazi podataka unutar LAN-a. Istovremeno rastu očekivanja za self-service i eksternu saradnju: klijenti žele provjeriti status narudžbi, razmjenjivati dokumente ili evidentirati reklamacije – bez VPN-a, bez raspoređivanja desktop-klijenta i bez lokalnih instalacija.

Delphi Desktop i Web-portali kombinovati u praksi znači spojiti ta dva svijeta tako da su operacija, sigurnost i konzistentnost podataka pod kontrolom. Ključno nije „prekopirati“ maske u preglednik, nego arhitektura koja čisto odvaja procese, prava i podatkovne tokove te omogućava obema front-endovima da rade prema zajedničkim pravilima. Dobit je put modernizacije bez Big-Bang pristupa: Desktop ostaje produktivan, dok web-portal raste kontrolisano.

Ovaj članak je namijenjen IT-u, administratorima i tehnički odgovornim za projekte. Fokus je na utjecajima na operacije, administraciju, sučelja, sigurnost, pohranu podataka i migraciju – manje se ulazi u detalje okvira. Dobit ćete praktične obrasce, kriterije odluka i tipične zamke s proaktivnim mjerama.

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 za distribuirane korisnike idealan, ali određeni zadaci su na desktopu efikasniji ili su uopće mogući samo tamo.

Snage desktopa koje u praksi vrijede

• Kompleksan unos podataka s vrlo gustim formama, radom preko tastature, velikim tabličnim prikazima i brzim prelascima između zapisa.
• Periferija i lokalne integracije poput etiketa štampača, skenera, serijskih uređaja ili specijalnih Windows-komponenti.
• LAN-niska performansa, kada se obrađuju velike količine podataka ili proces zahtijeva ekstremno nisku latenciju.
• Rastli workflowi s mnogim izuzecima, gdje 1:1 port u portal nosi visoke početne rizike.

Snage portala koje zadovoljavaju nove zahtjeve

• Eksterni pristup za kupce, dobavljače ili partnere bez potrebe za instalacijom klijenta.
• Centralna upravljivost (verzije, funkcije, privilegije) s jasnom vanjskom granicom.
• Nezavisnost uređaja (preglednik, mobilna upotreba) za terenski tim i menadžment.
• Ciljana otvaranja procesa kao što su provjere statusa, uploadi, odobrenja ili ticket-procesi.

U kombinaciji leži vrijednost: desktop ostaje power-alat za interne uloge, a portal postaje kontrolisani pristup za eksterne grupe korisnika. Da se to ne razdvaja u dvije paralelne „istine“, potreban je povezujući servisni sloj.

Kada kombinujete Delphi Desktop i Web-portale: tri ciljane arhitekture

Pri odluci arhitekture radi se prije svega o odgovornostima: gdje leži poslovno pravilo? Ko smije mijenjati podatke? Koja je sloj „Single Source of Truth“ (dakle odlučujući izvor pravila i stanja)? Za tehničke donosioce odluka važno je: izbor ima direktne posljedice 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 case-ove, tipično „čitati i inicirati“: statusi, dokumenti, odobrenja, jednostavni unosi. Za to se uvodi Delphi REST-API ili zaseban REST-server. Desktop aplikacija može u početku i dalje direktno pristupati bazi podataka.

Operativna prednost: brz start, mali zahvati u desktop, pogodno za prvi portalni benefit.

Rizična tačka: postoje dva podatkovna puta (Desktop → DB direktno, Portal → API). Ako su poslovna pravila samo u desktopu, mogu nastati nekonzistentnosti. Protumjera je: ciljano započeti funkcije portala tamo gdje su pravila jednostavno i serverski primjenjiva (npr. dostava dokumenata, provjera statusa, definirane akcije odobravanja).

Varijanta B: Servisni jezgro kao zajednički procesni sloj (preporučeno pri paralelnom radu)

Ovde 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), a pravila i validacije su serverski.

Operativna prednost: centralno mjesto za prava, audit, logiku statusa i validacije; dosljedno ponašanje preko svih frontenda.

Uložak: veći na početku, jer se moraju uredno isplanirati API-standardi, formati grešaka, verzioniranje, monitoring i deployment. Zbog toga se kasnije stvara znatno manji trošak jer postoji manje izuzetaka.

Varijanta C: Portal vodi, desktop ostaje kao specijalni klijent

Ova varijanta je razumna kad je browser strateški standardni pristup (npr. u jako distribuiranim organizacijama), dok desktop ostaje za uloge s posebnom opremom ili visokoproduktivnim unosom. Servisni jezgro u tom slučaju mora biti posebno stabilno i skalabilno.

Layer-3 arhitektura kao razumljiva smjernica

Bez obzira na varijantu, pomaže Layer-3 arhitektura: (1) prezentacija (Desktop/Portal), (2) aplikacijski i domeni sloj (use case-ovi, pravila), (3) infrastruktura (baza podataka, pohrana datoteka, messaging, eksterni sustavi). Za administratore je to važno jer se jasno definiraju operativne granice: šta je „frontend problem“, šta je „servis problem“, a šta leži u bazi ili storage-u? Takvo razdvajanje skraćuje potragu za greškama i smanjuje nuspojave pri deploymentima.

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

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

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

Česta mrtva točka je API koji samo preslikava DB tablice prema van („Create/Read/Update/Delete“). Tada se pravila moraju ponovno implementirati u portalu, a desktop zadržava svoje logike. Bolje su Use-Case-APIs: endpointi opisuju poslovne akcije kao „kreiraj reklamaciju“, „oslobodi nalog“, „uploaduj dokument“, „potvrdi status isporuke“.

Efekt u radu je opipljiv: validacije se događaju serverski, greške su reproducibilne, i oba klijenta (desktop i portal) pokreću isti tok preko iste logike.

2) Upravljati konfliktima i ponavljanjima

S pojavom portala raste vjerojatnost paralelnih izmjena i ponovljenih zahtjeva (npr. zbog timeouta, retry-a ili dvostrukog klika korisnika). Tri koncepta pomažu, bez uvođenja trajnih zaključavanja:

• Idempotentnost: kritične akcije su dizajnirane tako da ponavljanje daje isti efekt i ništa se ne izvrši dvaput. To se praktično postiže jedinstvenim ID-jem zahtjeva (Idempotency Key).
• Optimistic Concurrency: zapis nosi informaciju o verziji (npr. „Row Version“). Pri izmjeni servis provjerava da li se verzija podudara i jasno vraća konflikte.
• Kratke transakcije: umjesto zaključavanja „svih stavki“, operacije pisanja drže se kratko. Duži poslovi (npr. eksporti, paketni izvještaji) se izvršavaju asinkrono.

Za tehničke donosioce odluka važno je: ovi mehanizmi smanjuju opterećenje podrške jer su scenariji grešaka („dogodilo se dvaput“, „moja izmjena je nestala“) znatno rjeđi.

3) Jasno modelirati stanja i prijenose

Ako desktop rješava kompleksne slučajeve, a portal „samo“ dostavlja zahtjeve ili predfaze, potrebni su definirani prijelazi statusa. Praktična podjela može biti: portal stvara ili nadopunjuje zapise u jasno ograničenim statusnim područjima (npr. „podneseno“), desktop obrađuje specijalne slučajeve, servisni jezgro odlučuje i evidentira promjene statusa. Tako se izbjegava da portal-klijent nehotice „pokvari“ procese nepravilnom konfiguracijom.

Podaci i dokumenti: često podcijenjeno područje integracije

Gotovo svaki portal donosi rukovanje datotekama: uploadi, prilozi, otpremnice, slike, PDF-izlazi. Za administratore je to ključno jer utječe na backup, privilegije, provjeru virusa, troškove pohrane i performanse.

Gdje pohraniti datoteke: baza, fileshare ili object storage?

Postoje tri uobičajene opcije pohrane, svaka vodi različitoj operativnoj stvarnosti:

• Baza podataka (BLOB): dobra je kada transakcije moraju biti strogo vezane i kada backup/restore treba biti u jednom paketu. Nedostaci su često veće baze podataka i duži backup prozori.
• Filesystem/Share: tipično On-Prem, lako se integrira u postojeće backup koncepte. Važno je imati jasna prava i API-sloj koji kontrolira pristup.
• Objekt-Storage: smisleno pri skaliranju, pravilima životnog ciklusa ili kada se eksterni pristupi tehnički žele jasno kapsulirati. Potrebno je promišljeno upravljanje ključevima i modelom privilegija.

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

PDF-i i izvještaji: serverski umjesto dupliciranja

Delphi-desktop aplikacije često imaju rastuće tokove štampe i izvještavanja. Portali često trebaju iste sadržaje u PDF-u. Umjesto održavanja dvije implementacije, isplati se centralna generacija dokumenata u servisnom jezgru: predlošci, verzioniranje i izlazni formati su 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 miješana arhitektura

Odluka „Delphi ili C#“ za kompanije je manje ideološka, a više pitanje sposobnosti timova, operativnog okruženja i održivosti. U mnogim slučajevima miješana arhitektura je realna, dokle god su odgovornosti jasno odvojene.

Delphi kao servisna platforma: smisleno ako postoji poslovna logika

Ako je poslovna logika i pristup podacima već solidno implementiran u Delphi, Delphi-bazirani REST-server može biti efikasan. Za administratore i donosioce odluka važno je: vođenje servera nije „desktop koji stalno radi“. Produktivan servis treba jasnu konfiguraciju, uredne timeout-e, strukturirane logove, health-checkove i reproducibilan deployment.

Također, povezivanje s podacima treba modernizirati ako su još u igri stari drajveri ili BDE. BDE-Ablösung i prelazak na moderne pristupe smanjuju poremećaje u radu i olakšavaju deployment jer je manje legacy komponenti koje treba instalirati i održavati.

C# servisi u portal-ekosistemu: često zbog hostinga i identity

Ako portal nastaje u .NET-dominantnom krajoliku, C# servisi su često logičan izbor – ne najmanje zbog integracije identity-a, postojećih operativnih standarda i hostinga iza Microsoft IIS ili u kontejneriziranim platformama. Ključno je izbjeći dvostruku implementaciju: ili ostavite poslovnu jezgru u Delphi-servisima i neka C# rješava edge-teme (npr. portal-specifičnu orkestraciju), ili planirate kontrolisanu migraciju logike u .NET – ali tada sa jasnim granicama prema poslovnim oblastima.

API-Gateway: uređujući element, ali nije uvjet

API-gateway može objediniti centralne funkcije (routing, rate-limits, logging, autentikaciju). Za manje start-architekture često je dovoljan konzistentan API s jedinstvenim standardima. No čim postoji više servisa i grupa korisnika, gateway pomaže držati vanjsku ivicu stabilnom i centralno provoditi politike.

Autentikacija i prava: od internog desktopa do eksterne portal-svijeta

S portalom se mijenja krajolik korisnika: pored internih dolaze i eksterni nalozi, uloge i tenantnosti. To postavlja zahtjeve za identity, autorizacijom i auditabilnošću. Za administratore je bitno jer se identity-sistemi i modeli uloga kasnije teško mijenjaju.

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

U B2B postavkama široko je rasprostranjen SAML 2.0 (Single Sign-On preko Identity Providera), jer kompanije žele iskoristiti postojeće identitete. OIDC (OpenID Connect) je također uobičajen, osobito u modernijim platformama. Klasični korisnik/lozinka logini su mogući, ali nose dodatni rad na politici lozinki, MFA, reset-procesima i podršci.

Za arhitekturu važno: autentikacija (tko si?) i autorizacija (što smiješ?) moraju se provjeravati serverski – ne u portal-frontend-u.

Multitenantnost i model uloga: ne dodavati „kasnije“

Kupčev portal praktično uvijek zahtijeva razdvajanje tenanata: kupac vidi samo svoje podatke. To treba modelirati u servisnom jezgru, idealno putem:

• Claims u tokenu (npr. Tenant-ID, uloge, referenca ugovora), kako bi servisi mogli donositi odluke.
• Provjere po zapisu (row-level provjere u poslovnoj logici), a ne samo „sakrivanje menija“.
• Audit-trail za važne akcije (tko, što, kada), plus korelacija preko Request-ID za analizu grešaka.

Desktop može – po želji – također raditi s tokenima prema istom identity-stacku. To smanjuje izuzetke i olakšava praćenje izmjena, posebno kad portal i desktop rade na istom zapisu.

Modernizirati pristup podacima: FireDAC, PostgreSQL i kontrolisani podatkovni putevi

Mnoge Delphi-desktop-solucije historijski su izrasle s direktnim DB-pristupom. Kad se doda portal, to postaje arhitektonsko pitanje: podatkovni putevi moraju biti kontrolisani, validacije centralizirane, i performanse stabilne i pri paralelnom opterećenju.

FireDAC kao osnova za održiv pristup podacima

BDE-Ablösung mit nativer Anbindung je u Delphi okruženjima uobičajeni standard za pristup modernim bazama podataka. Važnije od same komponente je ujednačavanje: parametrizirani upiti, uredne transakcijske granice, jedinstveno rukovanje greškama i mjerljiva trajanja izvršavanja. Za operacije je važno da su timeout-i i potrošnja resursa planabilni i da se problemi prate u logovima i monitoring sustavu.

PostgreSQL s Delphi: dobro upravljivo uz jasan tip- i migracijski koncept

PostgreSQL s Delphi je robustan, pod uvjetom da su mapiranje tipova (npr. UUID, timestampi, JSON-polja), indeksi i shema-migracije uredno riješeni. Posebno portali generiraju mnoge filtrirane list upite. Zbog toga filtriranje, paginacija i sortiranje trebaju biti serverski implementirani, kako se ne bi nepotrebno prenosile velike količine podataka. To smanjuje opterećenje i poboljšava iskustvo korisnika, bez utjecaja na brzinu desktopa.

Operacije, deployment i monitoring: uspostaviti portal-ready stanje za Delphi backend

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

Windows-servis ili Linux-servis: bitan je operativni model

Delphi-servis može se vrtjeti kao Windows- i Linux-servisi ili kao Linux-daemon. Važnije od OS-a su standardi koji čine rad stabilnim:

• Health-Checks za monitoring i load-balancer (npr. „servis živi“ i „baza je dostupna“).
• Strukturirano logiranje (uključujući Request-ID, korisnik/tenant, trajanje, status kodove), kako bi se slučajevi podrške mogli reproducirati.
• Konfiguracija bez ponovnog build-a (npr. varijable okoline, centralne konfiguracijske datoteke) za automatizirane deploymente.
• Mogućnost rollback-a kroz jasne verzije i migracijski sigurne promjene u bazi podataka.

Profil opterećenja: portal = „mnogo kratkih zahtjeva“ umjesto „nekoliko dugih sesija“

Korištenje desktopa često stvara duže radne seanse po korisniku, dok portal generira mnogo kratkih, paralelnih zahtjeva. Tipične tehničke mjere su:

• konzistentna paginacija, serversko filtriranje i ograničene veličine odgovora
• keširanje za referentne podatke i rijetke upite
• asinkroni poslovi za duže zadatke (exporti, paketni izvještaji)
• rate-limiti i zaštitne mjere protiv zlonamjerne upotrebe

Za donosioce odluka ključno je: performansa nije „fino podešavanje na kraju“, već dio definicije API-ja (veličine odgovora, timeout-i, obrada u pozadini).

Modernizacija bez Big-Bang pristupa: održivi put u pet koraka

Potpuni novi razvoj rijetko je potreban i često je rizičan jer je procesno znanje ugrađeno u Delphi-klijentu. Dokazano je postupanje gdje je svaka faza produktivno upotrebljiva i ne ugrožava rad.

1) Inventura stanja: procesi, suverenitet podataka, integracije

Ne započinjite od maski, nego od use case-ova: koji tokovi idu u portal? Koje podatke eksterni korisnik smije vidjeti ili mijenjati? Koje su integracije s ERP-om, DMS-om ili CRM-om? Iz toga nastaje prioritetna lista API-ja koji donose stvarnu vrijednost.

2) Definirati servisne osnove: Auth, format grešaka, logiranje, verzioniranje

Ta osnova odlučuje o budućoj održivosti. Dogovorite rano standarde za autentikaciju/autorizaciju, konzistentan format grešaka, korelaciju zahtjeva, verzioniranje API-ja i telemetriju. To smanjuje trenja između portal-tima, backend-tima i operacija.

3) Isporuka prve portalne sekvence end-to-end

Odaberite proces s jasnom ograničavanjem (npr. dokumenti ili provjera statusa). Važno je da cijeli lanac funkcionira: login, provjera prava, API, UI, logiranje, monitoring, operacije. Organizacija tako rano vidi koji standardi stvarno rade u praksi.

4) Ciljano povezati desktop: kritične putanje pisanja preko servisa

Kad su servisi stabilni, premjestite odabrane desktop-funkcije: naročito promjene statusa, odobrenja ili centralne validacije. Desktop ostaje izvedbeno snažan, ali pravila postaju konzistentnija, a direktan DB-pisanje se postupno smanjuje.

5) Konsolidacija: ukloniti dupla pravila i izuzetke

U suprotnom s vremenom nastaju „dva sistema“. Planirajte redovite konsolidacije: koja pravila postoje dvaput? Gdje portal može koristiti desktop-servis? Koji izvještaji trebaju centralnu generaciju? Cilj je upravljiva platforma, ne dogma.

Tipične zamke iz operativnog pogleda – i kako ih izbjeći

Pravila se ponovno implementiraju u portalu

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

Nedorečenost vlasništva nad podacima između desktopa i portala

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

Sigurnost se tretira kao naknadni dodatak

Posebno kod kupčevih portala SSO, tenančne provjere, sigurni downloadi datoteka i audit trebaju biti uključeni od početka. Naknadno je skuplje i povećava rizik sigurnosnih propusta.

Nedostatak transparentnosti u operacijama

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

Zaključak: Servisno jezgro povezuje snagu desktopa s dometom portala

Kombinacija Delphi-desktopa i web-portala u mnogim kompanijama predstavlja najrealniji put za održavanje ključnih procesa uz omogućavanje eksterne suradnje. Presudno je da se ne upravlja dvjema odvojenim svjetovima, nego da se stvori povezujuće servisno jezgro: Use-Case-API-ji, čista prava, jasno praćeni statusi, kontrolisani podatkovni putevi i operativni model s logiranjem, monitoringom i planabilnim deploymentima.

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

U poslovnom kontekstu značajnu ulogu ima i Delphi Modernisierung, kada integracije, podatkovni tokovi i dalji razvoj moraju skladno surađivati.

Projekt ili plan modernizacije s Net-Base razmotrite.