Mnoge kompanije već godinama ili desetljećima u pogonu imaju stabilne Delphi-aplikacije koje pokrivaju jezgro njihovih procesa: obrada narudžbi, proizvodnja, servis, logistika, naplata, upravljanje uređajima, tokovi dokumenata. U tim sistemima nije prisutan samo kod, već i pouzdan sklad poslovnih pravila, modela podataka, korisničkog vođenja i operativnog iskustva. Upravo to čini modernizaciju zahtjevnom: stvarna vrijednost rijetko leži u korisničkom interfejsu, nego u razvijenoj poslovnoj logici.
Ako se modernizacija shvati kao „iznova graditi“, gubitak je zagarantovan. Ne zato što su nove tehnologije po definiciji loše, već zato što se implicitno znanje iz naslijeđa – posebni slučajevi, historijski podaci, izuzeci u procesima, regulatorni detalji – pri preseljenju često ne može potpuno rekonstruisati. Posljedica su skupe regresijske greške, promijenjena vremena procesa, problemi s prihvatanjem i projekat koji traje duže nego što je planirano.
Međutim, Delphi se vrlo dobro može modernizirati bez gubitka poslovne logike. Ključ je kontrolisani, postupni pristup: prvo stvoriti transparentnost (arhitektura, podaci, rizici), zatim odvojiti slojeve (UI, pristup podacima, domena/poslovna logika), potom modernizirati (DB drivere, Unicode/64-bit, API-je, servise, multiplatformu) – pri čemu se istovremeno osigurava kontinuirani rad sistema. Ovaj članak opisuje praktične obrasce modernizacije, tipične zamke i postupak koji funkcioniše u B2B okruženjima visoke procesne kritičnosti.
Zašto Delphi-modernizacija rijetko je „tehnički projekt“
U praksi modernizacije ne propadaju zbog nedostajućeg compiler-flag-a, nego zbog pogrešnih pretpostavki o ponašanju sistema. Delphi-aplikacije koje su godinama nadograđivane često sadrže:
- Poslovna pravila u GUI-eventima (OnClick, OnExit, OnValidate), često razbacana po mnogim formama
- SQL izraze „blizu površine“ optimizirane godinama za tačno jednu bazu podataka
- Zaobilaženja za historijske podatke, posebne slučajeve, varijante klijenata ili logiku više poslovnih jedinica
- Batch-procese koji u praksi rade u fiksnim terminima i imaju međuzavisnosti
- Integracije u ERP, DMS, CRM ili mašine koje su slabo dokumentovane
- Tiho znanje u obliku operativnih rutina: „Ako greška X, prvo provjeri Y”
Ko započne s Big-Bang-rewriteom, mora sva ta znanja ponovo proizvesti – uključujući i greške koje stara rješenja više ne proizvode. Bolji pristup je tretirati poslovnu logiku kao imovinu: prvo je izolirati, zatim osigurati, pa tek onda modernizirati.
Modernizacija bez gubitka logike: cilj i vodilje
Održiv cilj za B2B sisteme nije „sve novo“, nego arhitektura koja omogućava promjene. Tipične karakteristike:
- Odvojene odgovornosti (UI, domena/poslovna logika, pristup podacima, integracije)
- Testabilnost i mjerljivost (regresioni testovi, logging, monitoring, reproducibilni buildovi)
- Postepena zamjenjivost (modernizirati UI bez odmahšnjeg preslaganja modela podataka; migrirati DB bez pisanja novog UI‑ja)
- API‑sposobnost (REST-Server ili servisni sloj za povezivanje portala, mobilnih klijenata i integracija)
- Operabilnost (Windows- i Linux-servisi, jasne politike deploya, rollback strategija)
U Delphi je to posebno ostvarivo, jer možete ponovno koristiti postojeće jedinice i domenske klase dok modernizujete okolinu: pristup podacima od BDE prema BDE-Ablösung mit nativer Anbindung, novi REST-endpoints, novi UI‑moduli, novi deploymenti.
Inventar: šta zaista mora ostati
Prije nego što se „dirne“ kod, isplati se strukturirana inventura. Cilj nije potpuna dokumentacija, nego pouzdana osnova za odluke.
1) Mapa poslovne logike umjesto maratona čitanja koda
Praktično se dokazala mapa poslovne logike s ovim perspektivama:
- Use‑caseovi: Koji su ključni poslovni tokovi? (npr. kreiranje naloga, faktura, storno, povrat robe, servis mašina, ugovor o održavanju)
- Pravila: Koje validacije, kalkulacije, automati stanja postoje?
- Varijante: Više poslovnih jedinica, konfiguracije klijenata, zemljopisno specifična pravila
- Sekalacije: Import/Export, ERP/DMS/CRM, uređaji/protokoli
- Batch/Jobs: noćni radovi, izvještaji, sinhronizacije podataka
Iz ove karte nastaju prioritetni paketi modernizacije: šta mora ostati stabilno, šta smije biti promijenjeno, šta može pričekati.
2) Uočiti tehnički dug
Tipični tehnički dug u starijim Delphi‑sistemima:
- Borland BDE/Paradox zavisnosti
- ANSI‑stringovi/neriješena Unicode migracija
- Samo 32‑bit, zastarjele komponente trećih strana
- Monolitična logika formi, globalne varijable, unit‑i s efektima na stranu
- Neprecizne transakcione granice i „SQL svugdje”
Vještina je ne tretirati te točke dogmatski kao nešto što se odmah mora ukloniti, već postaviti redoslijed koji minimizira rizik i maksimizira poslovnu vrijednost.
Arhitekturno odvajanje: poluga protiv gubitka logike
Najčešći razlog gubitka logike je pomiješanost UI‑ja, pristupa podacima i poslovnih pravila. Modernizacija stoga počinje odvajanjem – a ne „novim UI frameworkom”.
Layer-3 arhitektura kao pragmatično ciljano stanje
Za mnoge postojeće Delphi aplikacije dobro radi Layer-3 arhitektura:
- Presentation Layer: VCL/FMX forme, ViewModels/Presenteri, validacija zadržana blizu UI (format, obavezna polja)
- Business Layer: domenski modeli, servisi, pravila, logika stanja, kalkulacije
- Data/Integration Layer: repozitoriji, SQL/ORM dijelovi, adapteri za integracije, REST-klijenti, messaging
Dobitak: poslovna logika postaje testabilna i ponovo upotrebljiva. Kasnije isti domenski servisi mogu koristiti kupčev portal, REST-server ili Linux‑servis. Na taj način modernizirate „vanjsku koru“ bez ponovnog izmišljanja jezgre logike.
Strangulation Pattern: Postepeno „prihvatiti“ stari sistem
Jedan provjeren migracioni obrazac je Strangulation Pattern: nove funkcije se razvijaju već u novoj strukturi (npr. domenski servis + repozitorij), dok se postojeće forme postupno prepravljaju. Stari sistem ostaje operacionalan, ali ga korak po korak zamjenjujete novim.
Ključno je aktivno preusmjeravanje zavisnosti: ne „forma poziva SQL“, nego „forma poziva servis“, a servis odlučuje. Ta mala inverzija često donese najveću korist.
Modernizacija pristupa podacima: BDE-Ablösung i FireDAC pažljivo planirati
Centralni korak modernizacije je BDE-Ablösung. Kompanije često podcijene da se ne radi samo o driverima, već o SQL semantici, transakcijama, lockingu, tipovima podataka i ponašanju pri greškama. Moderni Delphi stackovi tipično se oslanjaju na BDE-Ablosung mit nativer Anbindung s nativnim driverima (npr. za MariaDB/MySQL, PostgreSQL, SQL Server).
Šta se pri prelasku zaista odlučuje
- Ciljna baza podataka: Ostaje li postojeća DB? Ima li smisla preuređenje baze (npr. s Paradox/Firebird na MariaDB ili PostgreSQL)?
- Transakcioni model: Gdje počinju/koordiniraju transakcije? Koji use‑caseovi moraju biti atomarni?
- Konkurentnost/Locking: Optimistički vs. pesimistički, tretman deadlockova, strategije ponovnog pokušaja
- SQL dijalekt: funkcije za datum, ponašanje stringova, NULL‑handling, case‑senzitivnost
- Performanse: indeksi, planovi upita, paging, batch‑inserti
Poslovna logika je usko vezana uz ponašanje podataka. Ako migraciju obavite „usput“, rizikujete suptilne razlike u praksi: zaokruživanja, sortiranja, granice datuma, konflikte zaključavanja. Zato podatkovni sloj mora rano ući u plan modernizacije, uključujući put migracije i strategiju testnih podataka.
Pragmatski koraci ka FireDAC migraciji
Umjesto potpunog „remonta“ aplikacije odjednom, iskustvo pokazuje sljedeći redoslijed:
- Uvođenje sloja pristupa podacima (Repository/DAO) kao fasade
- Prebacivanje pojedinih use‑caseova na FireDAC (npr. prvo „čitanje“, kasnije „pisanje“)
- Ujednačavanje rukovanja konekcijama, obrade grešaka, logiranja
- Postepeno gašenje BDE komponenti tamo gdje je fasada stabilna
Tako aplikacija ostaje u svakom trenutku isporučiva, izbjegavajući dugo razdoblje „polu‑dovršeno”.
Unicode, 64‑Bit i zavisnosti: zamke modernizacije u detalju
Mnoge modernizacije ne zakazu zbog koncepta, nego zbog podcijenjenih detalja. Tri su posebno česta u Delphi projektima.
Unicode migracija: nije samo o stringovima, već o tokovima podataka
U vrlo starim Delphi verzijama sistemi potječu iz ANSI svijeta. Unicode migracija se tiče:
- Tipova stringova i konverzija (WideString/AnsiString/UnicodeString)
- Rukovanja datotekama i putanjama (Windows-API, mrežne putanje)
- Import/Export (CSV, fiksne širine polja, EDI, legacy‑sistemi)
- Sortiranja/kolaicija u bazi podataka
Ključno je identificirati kritične tokove podataka (npr. tekstovi na fakturama, nazivi artikala, međunarodne adrese) i za njih postaviti regresione testove. Unicode nije samo „re‑engineering“, nego kontinuirani proces osiguranja kvaliteta.
Prijelaz na 64‑bit: nije samo pitanje memorije
Prelazak na 64‑bit često se svodi na „veličinu pointera“. U praksi su važniji:
- Zastarjele komponente trećih strana bez 64‑bit podrške
- COM/ActiveX zavisnosti
- DLL‑i i driveri (barcode, uređaji, kriptografija, potpis)
- Installer/deployment i registry‑putanje (WOW64)
Smarna strategija je prvo inventarisati sve eksterne zavisnosti i definirati alternative. Tek tada je 64‑bit korak planabilan – i ne iznenadi vas neposredno pred release.
Windows 11 ARM64: provjeriti rano umjesto platiti kasnije
S pojavom Windows 11 ARM64 pojavljuje se nova klasa ciljnih sistema. Čak i ako ne svaka kompanija odmah treba native ARM64 buildove, pametno je rano provjeriti:
- Postoje li native zavisnosti (DLL‑i, driveri) koje na ARM64 neće raditi?
- Oslanja li se aplikacija na emulaciju i je li to prihvatljivo?
- Kako izgleda installer, update/repair proces?
U modernizacijskim projektima ovo je tipično „kasna“ tema koja postane skupa. Bolje: uključiti je rano u roadmap platforme i tehnički razjasniti.
REST-Server i servisi: učiniti poslovnu logiku dostupnom portalima i integracijama
Mnogo kompanija ne modernizira Delphi zato što desktop‑app izgleda staro, nego zato što se javljaju nove potrebe: kupčev portal, pristupi partnera, mobilni procesi, integracija s ERP/DMS/CRM, reporting‑pipelineovi. Za to su potrebni jasni interfejsi. REST‑server često je najsmisleniji most.
API prvo? Samo ako prava i domena idu uz njega
API je koristan samo ako provodi istu poslovnu logiku kao klijent. U suprotnom nastaju dva skupa pravila: jedan u desktop klijentu, drugi u backendu. Posljedice su nekonzistentnosti i sigurnosni propusti.
Zato bi REST‑serverski sloj trebao što direktnije sjedati na domenske servise. Tipični elementi:
- Autentifikacija/autorizacija (uloge, poslovne jedinice, prava)
- DTO‑i/serijalizacija s jasnim pravilima verzioniranja
- Transakcioni i greškovni koncept (HTTP statusi, Problem‑Details, logging)
- Idempotentnost i konkurentnost (za retries, obradu iz reda)
Tako REST‑server postaje stabilna tačka integracije – a ne „drugi klijent”.
Modernizacija Linux‑servisa i Windows servisa
Batch procesi i integracije u mnogim kompanijama rade kao Windows servisi, Task Scheduler jobovi ili čak „skriveni” desktop instance. Pri modernizaciji vrijedi konsolidovati:
- Razdvajanje UI‑ja i pozadinske logike
- Konfigurisani rasporedi izvođenja i jasni operativni parametri
- Čisto logiranje (strukturirani logovi, korelacija po jobu/zahtjevu)
- Mogućnost pokretanja servisa pod Linux (npr. za containerizirane deploymente)
Prednost nije samo „modernost”, već operativna: reproducibilan rad, manje manuelnih intervencija, lakše otkrivanje grešaka.
UI modernizirati bez diranja jezgre: VCL, FMX i hibridni pristupi
Mnogi planovi modernizacije počinju od UI‑ja. To može biti smisleno – dokle god je jasno šta se time postiže. Ako je poslovna logika odvojena, UI se može znatno sigurnije obnoviti.
Postepena modernizacija VCL‑aplikacija
VCL u mnogim B2B scenarijima i dalje predstavlja solidan izbor, posebno u okruženjima gdje dominira Windows i potrebna je visoka produktivnost na desktopu. Modernizacija može značiti:
- Smanjiti UI‑logiku (Presenter/ViewModel), premjestiti poslovna pravila u servise
- Očistiti skup komponenti, konsolidovati vlastite kontrole
- Poboljšati responzivnost (Async, background jobovi, progress, Cancel)
- Pristupačnije korisničko sučelje, konzistentna validacija, jasnije poruke o greškama
To donosi opipljiv benefit bez podrazumjevane potpune prerade interfejsa.
Delphi multiplatforma: kada ima smisla FMX
Ako postoje stvarni multiplatform zahtjevi (Windows, macOS, eventualno Linux u kontekstu servisa), FMX može biti opcija. Ključno je očekivanje: multiplatforma nosi dodatne troškove testiranja i integracije (fontovi, print, OS dijalozi, datotečni sustav, pakovanje/deployment). Troškovi su predvidljivi ako poslovna logika već leži u čistom sloju.
Čest pragmatičan put je hibrid: VCL ostaje za Windows‑klijenta, dok se novi front‑endovi (portal, mobilna aplikacija) povezuju preko REST‑servera. Na taj način postižete multiplatformu preko granica sistema, a ne preko jednog UI‑stacka.
Testiranje i regresija: kako „pribiti” poslovnu logiku
„Gubitak poslovne logike” u praksi znači: sistem u rubnim slučajevima daje drugačije rezultate. To rijetko bude odmah uočljivo, ali je skupo. Zato testabilnost nije luksuz, nego alat modernizacije.
Zlatni use‑caseovi i referentni podaci
Pokazalo se korisnim imati skup „zlatnih” use‑caseova: realni, kritični tokovi s definisanom početnom podacima i očekivanim rezultatima (npr. lanac dokumenata od ponude do dobiti, ili nalog za održavanje s dijelovima i evidencijama radnog vremena). Oni se uspostavljaju kao regresioni testovi ili barem ponovljivi test skripti.
Važno: ne samo uspješni putevi, nego i tipični putevi grešaka (konflikti zaključavanja, nedostatak prava, nepotpuni master podaci, duplikat import datoteke).
Automatizacija tamo gdje daje najveći učinak
Ne svaki naslijeđeni projekat treba odmah 80% pokrivenosti unit testovima. Visok ROI često donosi automatizacija u oblastima:
- Domenski servisi (kalkulacije, pravila, promjene stanja)
- Pristup podacima s jasnim ugovorima (mapiranje, SQL, transakcije)
- API testovi (auth, prava, verzioniranje)
Cilj je stabilnost pri promjenama, a ne akademska metrika.
Proces u praksi: plan modernizacije po etapama
Iz B2B perspektive modernizacija mora ostati isporučiva. Tipičan plan koji se vodi prema rizicima:
Etapa 1: Analiza, ciljna arhitektura, Quick Wins (2–6 tjedana)
- Mapa sistema (moduli, baze podataka, interfejsi, jobovi, zavisnosti)
- Matrix rizika (BDE, treće strane, 32/64‑bit, Unicode, deployment)
- Definicija ciljane arhitekture (Layer-3, servisni sloj, API strategija)
- Quick Wins: stabilizirati build proces, poboljšati logging, urediti verzioniranje
Etapa 2: Odvajanje poslovne logike (kontinuirano, inkrementalno)
- Identificirati domenske servise i izvući ih iz formi
- Uvesti repository‑fasade
- Prvi regresioni testovi za kritične use‑caseove
Etapa 3: Modernizacija pristupa podacima/DB sloja
- Uvesti FireDAC, utvrditi koncept konekcija i transakcija
- BDE‑Ablösung modularno (ili migracija baze s paralelnim radom)
- Testirati performanse i ponašanje zaključavanja pod opterećenjem
Etapa 4: Nadogradnja REST‑servera i integracija
- API s authom, pravima, verzioniranjem
- Povezivanje portala/integracija bez dupliranja logike
- Konsolidacija servisa za batch i pozadinske procese
Etapa 5: Platforma i UI‑odluke (64‑Bit, ARM64, multiplatforma)
- 64‑bit build, zamjena zavisnosti
- Provjera/planiranje ARM64 kompatibilnosti
- UI modernizacija: osvježenje VCL‑a ili FMX/hibrid, na osnovu poslovne koristi
Redoslijed je namjerno odabran tako da prvo dobijete transparentnost, zatim stabilizirate jezgro i tek nakon toga veliki „vidljivi” zahvati. Time se smanjuje rizik i rad ostaje predvidljiv.
Tipični anti‑patterni: šta modernizacije nepotrebno poskupljuje
Neki obrasci se u auditima i spašavanjima projekata stalno ponavljaju:
- „Radimo novo i preuzimamo samo feature‑e”: gotovo uvijek vodi gubitku logike jer nedostaju posebni slučajevi.
- API kao paralelni svijet: poslovna pravila ostaju u klijentu, a backend ih iznova definira.
- Promjena baze bez semantičkih testova: isti podaci, ali drugačije ponašanje (NULL, sortiranje, logika datuma).
- Prekasno upravljanje zavisnostima: 64‑Bit/ARM64 propada zbog male DLL neposredno pred Go‑Live.
- „Refaktoring prvo” bez ciljane slike: mnogo promjena, malo mjerljive koristi, visoka regresija.
Protivni prijedlog je uvijek isti: prvo razjasnite ciljnu arhitekturu i rizike, zatim inkrementalno gradite, pri čemu testirate i činljivo prikazujete poslovnu logiku.
Zaključak: modernizirati znači sačuvati – i ciljano proširiti
Modernizacija Delphi bez gubitka poslovne logike nije kontradikcija, već disciplina. Kompanije ne moraju birati između „sve zadržati” i „sve zamijeniti”. Uz jasnu arhitektonsku separaciju (npr. Layer-3), kontrolisanu BDE‑Ablösung prema FireDAC, API strategiju preko REST‑servera i jasan plan za Unicode, 64‑bit i nove platforme kao što je Windows 11 ARM64 moguće je postepeno prevesti razvijeni sistem u održivu, budućnosti‑otpornu strukturu.
Ključna stvar je tretirati poslovnu logiku kao centralno sredstvo: izolirati, učiniti testabilnom, pa tek onda modernizirati. Tako nastaje arhitektura koja podržava portale, servise i multiplatformne zahtjeve, bez ugrožavanja kontinuiranog rada.
Ako planirate Delphi Modernisierung i želite uredno objediniti poslovnu logiku, pristup podacima i operacije, razgovarajte s nama o realnom migracijskom putu: https://net-base-software-gmbh.de/kontakt/