Sok vállalat évek vagy évtizedek óta üzemeltet stabil Delphi-alkalmazásokat, amelyek a folyamataik magját képezik: rendelésfeldolgozás, gyártás, szolgáltatás, logisztika, elszámolás, eszközkezelés, dokumentum-workflow-k. Ezekben a rendszerekben nem csupán kód található, hanem egy megbízható együttműködés szakmai szabályokból, adattáblákból, felhasználói vezérlésből és üzemeltetési tapasztalatból. Pont ez teszi a modernizálást kihívássá: az igazi érték ritkán a felületen van, hanem a felhalmozódott szaklogikában.
Ha a modernizálást „újraépítésként“ értelmezik, a logika elvesztése előre programozott. Nem azért, mert az új technológiák maguk rosszak lennének, hanem mert a migráció során az örökölt, implicit tudás — különleges esetek, történeti adatok, folyamat-kivételkezelések, szabályozási részletek — gyakran nem rekonstruálható teljeskörűen. Ennek eredménye drága regressziós hibák, megváltozott folyamatidők, elfogadási problémák és egy projekt, amely tovább tart a tervezettnél.
Delphi azonban nagyon jól modernizálható úgy, hogy a szaklogika megmarad. A kulcs egy kontrollált, lépésről lépésre vezetett megközelítés: először átláthatóságot teremteni (architektúra, adatok, kockázatok), aztán szétkapcsolni (UI, adat-hozzáférés, domainlogika), majd modernizálni (adatbázis-illesztőprogramok, Unicode/64-Bit, API-k, szolgáltatások, többplatform) — miközben a folyamatban lévő üzemet biztosítjuk. Ez a cikk gyakorlati modernizálási mintákat, tipikus buktatókat és egy olyan eljárást ismertet, amely B2B környezetben, magas folyamatkritikalitás mellett működik.
Miért ritkán „csupán” műszaki projekt a Delphi-modernizáció
A gyakorlatban a modernizációk nem egy hiányzó fordítóflag miatt buknak el, hanem a rendszer viselkedésére vonatkozó téves feltevések miatt. Az éveken át bővített Delphi-alkalmazások gyakran tartalmaznak:
- szakmai szabályokat GUI-eseményekben (OnClick, OnExit, OnValidate), gyakran sok formon szétszórva
- SQL-utasításokat „közel a felülethez“, amelyek évek óta pontosan egy adatbázisra vannak optimalizálva
- megoldásokat történeti adatokra, különleges esetekre, ügyfélvariánsokra vagy multibérlő logikára
- batch-folyamatokat, amelyek a gyakorlatban fix időpontokban futnak és egymásra épülnek
- ERP, DMS, CRM vagy gépek felé történő integrációkat, amelyek alig dokumentáltak
- csendes tudást üzemeltetési rutinként: „Ha X hiba, akkor előbb Y-t ellenőrizni”
Akinek Big-Bang jellegű átírással kezd, annak ezt a tudást újra kell előállítania — beleértve azokat a hibákat is, amelyeket a régi megoldás már rég nem produkál. A jobb megközelítés az, ha a szaklogikát vagyontárgyként kezelik: először izolálni, majd biztosítani, végül modernizálni.
Modernizálás logika-veszteség nélkül: célkép és vezérelvek
Egy fenntartható célkép B2B rendszerekhez nem az „mindent újra”, hanem egy olyan architektúra, amely lehetővé teszi a változtatásokat. Tipikus jellemzők:
- Szétválasztott felelősségek (UI, domain/szaklogika, adat-hozzáférés, integrációk)
- Tesztelhetőség és mérhetőség (regressziós tesztek, naplózás, monitoring, reprodukálható build-ek)
- Lépésenkénti cserélhetőség (UI modernizálása anélkül, hogy azonnal az adattáblát át kellene alakítani; adatbázis migrálása UI újraírása nélkül)
- API-képesség (REST-Server vagy szolgáltatá réteg, hogy portálok, mobil és integrációk csatlakozhassanak)
- Üzemeltethetőség (Windows- és Linux-Services, világos deployok, rollback-stratégia)
Delphi esetén ez különösen jól elérhető, mert a meglévő unitok és domainosztályok továbbhasználhatók, miközben a külső rétegeket modernizálják: adat-hozzáférés átkötése BDE-ről BDE-Ablösung natív csatlakozással, új REST-endpointok, új UI-modulok, új deploymentek.
Bestandsaufnahme: Mi az, amit ténylegesen meg kell őrizni?
Mielőtt a kódhoz „hozzányúlnának“, érdemes strukturált felmérést végezni. A cél nem a teljes dokumentáció, hanem egy megbízható döntési alap.
1) Szaklogika-térkép a kódolvasó maraton helyett
Gyakorlatilag bevált egy szaklogika-térkép készítése a következő nézőpontokkal:
- Use-case-ek: Melyek a kritikus üzleti folyamatok? (pl. megrendelés felvétele, számla, sztornó, visszaszállítás, gépszerviz, karbantartási szerződés)
- Szabályok: Milyen validációk, számítások, állapotgép-logikák léteznek?
- Variánsok: Bérlők, ügyfélkonfigurációk, országonként eltérő szabályok
- Kimenetek: Import/Export, ERP/DMS/CRM, eszközök/protokollok
- Batch/Jobs: éjszakai futtatások, riportok, adategyeztetések
Erről a térképről prioritizált modernizációs csomagok készíthetők: mi maradjon stabil, mi változhat, mi jöhet később.
2) Technikai adósságok láthatóvá tétele
Idősebb Delphi-rendszerek tipikus technikai adósságai:
- Borland BDE/Paradox-függőségek
- ANSI-stringek/hiányzó Unicode-migráció
- 32-Bit-only, elavult harmadik féltől származó komponensek
- Monolitikus form-logika, globális változók, mellékhatásokat okozó unitok
- Nem egyértelmű tranzakcióhatárok és „SQL mindenhol”
A művészet az, hogy ezeket a pontokat ne dogmatikusan „eltakarítsuk”, hanem olyan sorrendet határozzunk, amely minimalizálja a kockázatot és maximalizálja az üzleti értéket.
Architekturális szétkapcsolás: a fogó a logika-vesztés ellen
A logika-vesztés leggyakoribb oka az UI, az adat-hozzáférés és a szakmai szabályok összekeveredése. A modernizálás ezért szétkapcsolással kezdődik — nem egy „új UI-keretrendszerrel”.
Layer-3 architektúra mint pragmatikus célállapot
Sok Delphi-legacy alkalmazásnál egy Layer-3 Architektur nagyon jól működik:
- Presentation Layer: VCL/FMX-Forms, ViewModels/Presenter, validáció csak UI-hez közeli (formátum, kötelező mezők)
- Business Layer: domainmodellek, szolgáltatások, szabályok, állapotlogika, számítások
- Data/Integration Layer: repository-k, SQL/ORM-elemek, interfész-adapterek, REST-kliensek, messaging
A haszon: a szaklogika tesztelhetővé és újrahasznosíthatóvá válik. Később egy ügyfélportál, egy REST-Server vagy egy Windows- und Linux-Services pontosan ugyanazokat a domain-szolgáltatásokat tudja használni. Így a „külső héjat“ modernizálják anélkül, hogy a maglogikát újra kellene feltalálni.
Strangulation Pattern: a régi rendszer fokozatos „körülölelése”
Egy bevált migrációs minta a Strangulation Pattern: az új funkciók már az új struktúrában keletkeznek (pl. domainservice + repository), miközben a meglévő formokat fokozatosan átalakítják. A régi világ működőképes marad, de darabonként új komponensek váltják fel.
Fontos, hogy az függőségeket aktívan megfordítsuk: ne „a form hívja az SQL-t”, hanem „a form hív egy service-t”, és a service dönt. Ez a kis irányváltás gyakran hozza a legnagyobb előnyt.
Adat-hozzáférés modernizálása: BDE-Ablösung és FireDAC tiszta tervezése
Egy központi modernizációs lépés a BDE-kiváltás. A vállalatok gyakran alábecsülik, hogy itt nem csupán driver-specifikus kérdésről van szó, hanem az SQL-szemantikáról, tranzakciókról, zárolásokról, adattípusokról és hibakezelésről. A modern Delphi-stackek jellemzően BDE-Ablosung mit nativer Anbindung-re építenek natív meghajtókkal (pl. MariaDB/MySQL, PostgreSQL, SQL Server esetén).
Mi az, amit az átkapcsoláskor valóban eldöntünk
- Adatbázis cél: marad-e a meglévő DB? Érdemes-e adatbázis-átalakítást végezni (pl. Paradox/Firebird-ről MariaDB-re vagy PostgreSQL-re)?
- Tranzakciós modell: hol kezdődnek/végződnek a tranzakciók? Mely use-case-eknek kell atomikusnak lenni?
- Párhuzamosság/Zárolás: optimista vs. pesszimista, hol kezeljük a deadlock-okat, retry-stratégiák
- SQL-dialektus: dátumfüggvények, string-viselkedés, NULL-kezelés, case-sensitivity
- Teljesítmény: indexek, lekérdezési tervek, lapozás, batch-insert-ek
A szaklogika szorosan kapcsolódik az adatviselkedéshez. Aki „mellékesen” migrálja az adatbázist, az a gyakorlatban finom eltéréseket kockáztat: kerekítések, rendezések, dátumhatárok, zárolási ütközések. Ezért az adatréteg korán kerüljön be a modernizációs tervbe, beleértve a migrációs útvonalat és a tesztadat-stratégiát.
Pragmatikus lépések a FireDAC-migrációhoz
Ahelyett, hogy az alkalmazást egyben újraépítenék, az alábbi sorrend vált be:
- Adat-hozzáférési réteg bevezetése (Repository/DAO) mint homlokzat
- Egyes use-case-ek átállítása FireDAC-re (pl. először olvasás, később írás)
- Connection-kezelés, hibakezelés, naplózás egységesítése
- BDE-komponensek fokozatos lekapcsolása, ahol a homlokzat stabil
Így az alkalmazás bármikor szállítható marad, és elkerülhető az a hosszú időszak, amikor „minden félkész”.
Unicode, 64-Bit és függőségek: a modernizálás részleteinek csapdái
Sok modernizáció nem a koncepció miatt bukik el, hanem alábecsült részletkérdések miatt. Három ilyen téma különösen gyakori Delphi-projektekben.
Unicode-migráció: nem csak stringek, hanem adatfolyamok
Nagyon régi Delphi-verziók ANSI-világból erednek. A Unicode-migráció akkor érinti:
- string-típusokat és konverziókat (WideString/AnsiString/UnicodeString)
- fájl- és útvonalkezelést (Windows-API, hálózati elérési utak)
- import/export-ot (CSV, rögzített mezőhosszok, EDI, legacy interfészek)
- rendezés/kolláció az adatbázisban
Döntő fontosságú a kritikus adatfolyamok azonosítása (pl. számlaszövegek, cikknév, nemzetközi címek) és ezekre regressziós tesztek felállítása. A Unicode inkább folyamatos minőségügyi folyamat, mint egyszeri „átépítés”.
64-Bit átállás: a memória nem az egyetlen kérdés
A 64-Bit-re váltást gyakran egyszerű pointer-méretekre redukálják. A gyakorlatban inkább ezek jelentkeznek:
- elavult harmadik féltől származó komponensek 64-Bit támogatás nélkül
- COM/ActiveX-függőségek
- DLL-ek és driverek (vonalkód, eszközök, kriptográfia, aláírás)
- telepítő/deploy és registry-útvonalak (WOW64)
Érdemes először felmérni az összes külső függőséget és alternatívákat definiálni. Ezután a 64-Bit-lépés tervezhetővé válik — nem lesz utolsó pillanatos meglepetés a kiadás előtt.
Windows 11 ARM64: korai ellenőrzés jobb, mint késői költségek
Windows 11 ARM64 megjelenésével egy új célplatform-osztály lép be. Még ha nem is minden vállalatnak kell azonnal natív ARM64 build, érdemes korán ellenőrizni:
- vannak-e natív függőségek (DLL-ek, driverek), amelyek ARM64 alatt nem futnak?
- alkalmazás emulációra szorul-e, és ez elfogadható-e?
- hogyan néz ki a telepítő, az update/repair folyamata?
Modernizációs projektekben ez tipikus „késői” téma, amely később költséges lesz. Jobb korán beépíteni a platform-roadmapbe és technikailag tisztázni.
REST-Server és szolgáltatások: a szaklogika portálokhoz és integrációhoz elérhetővé tétele
Sok vállalat nem azért modernizálja Delphi-ját, mert a desktop app „elavultnak” tűnik, hanem mert új követelmények jelentkeznek: ügyfélportál, partnerhozzáférések, mobil folyamatok, integráció ERP/DMS/CRM-mel, riporting-pipelinek. Ehhez tiszta interfészekre van szükség. Egy REST-Server gyakran a legpraktikusabb híd.
API először? Csak ha a jogok és a domainlogika is követik
Az API csak akkor nyerő, ha ugyanazt a szaklogikát érvényesíti, mint a kliens. Ellenkező esetben két szabályrendszer keletkezik: egy a desktopon, egy a backendben. Ennek következménye az inkonzisztencia és a biztonsági rések.
Ezért egy REST-Server rétegnek lehetőleg közvetlenül a domainservice-ekre kell támaszkodnia. Tipikus elemek:
- hitelesítés/autorizáció (szerepkörök, bérlők, jogosultságok)
- DTO-k/szerializáció világos verziózó szabályokkal
- tranzakciós és hibakezelési koncepció (HTTP státuszok, Problem-Details, naplózás)
- idempotencia és párhuzamosság kezelése (retry-k, queue-feldolgozás)
Így a REST-Server stabil integrációs ponttá válik — nem lesz a „második kliens”.
Linux-Services és Windows szolgáltatások modernizálása
A batch-folyamatok és integrációk sok vállalatnál Windows szolgáltatásként, Task Scheduler feladatként vagy akár „rejtett” desktop-instanciaként futnak. A modernizáláskor érdemes konszolidálni:
- UI és háttérlogika szétválasztása
- konfigurálható futási ütemek és világos üzemeltetési paraméterek
- tisztább naplózás (strukturált logok, korreláció munkára/kérésre)
- opció, hogy a szolgáltatásokat Linux alatt futtassák (pl. konténerizált deployokhoz)
Az előny nem csupán „modern”, hanem operatív: reprodukálható üzem, kevesebb manuális beavatkozás, jobb hibakeresés.
UI-modernizálás a mag érintése nélkül: VCL, FMX és hibrid megoldások
Sok modernizációs terv a UI-val kezdődik. Ez értelmes lehet — ha világos, mit nyerünk vele. Ha a szaklogika szét van kapcsolva, a UI kockázatmentesebben megújítható.
VCL-alkalmazások lépésenkénti modernizálása
A VCL sok B2B forgatókönyvben továbbra is robusztus választás, különösen olyan környezetekben, ahol Windows-központú és magas asztali termelékenység szükséges. A modernizálás lehet:
- UI-logika csökkentése (Presenter/ViewModel), szakregulák szolgáltatásokba helyezése
- komponens-landscape megtisztítása, saját controlok konszolidálása
- responsiveness javítása (Async, háttérfeladatok, progress, cancel)
- akadálymentes használat, következetes validáció, jobb hibaüzenetek
Ez kézzelfogható hasznot ad anélkül, hogy a teljes felületet újra kellene írni.
Delphi Multiplatform: mikor érdemes FMX
Ha valódi többplatformos igények jelentkeznek (Windows, macOS, adott esetben Linux szolgáltatási kontextusban), az FMX opció lehet. Döntő a várakozás: a többplatformos megoldás több teszt- és integrációs munkát jelent (betűtípusok, nyomtatás, OS-dialógusok, fájlrendszer, csomagolás/deploy). A költségek jól kalkulálhatók, ha a szaklogika már tiszta rétegben van.
Gyakori, pragmatikus út a hibrid megoldás: a VCL marad a Windows-kliensekhez, míg új front-endek (portál, mobil app) a REST-Serveren keresztül kapcsolódnak. Így a multiplatform a rendszerhatárokon keresztül jön létre, nem egyetlen UI-stack-re támaszkodva.
Tesztelés és regresszió: hogyan rögzítsük a szaklogikát
A „szaklogika elvesztése” a gyakorlatban azt jelenti, hogy a rendszer szélsőséges esetekben más eredményt ad. Ez ritkán azonnal látható, de költséges. Ezért a tesztelhetőség nem luxus, hanem a modernizálás eszköze.
Arany use-case-ek és referenciaadatok
Bevált gyakorlat egy „arany” use-case készlet: valós, kritikus folyamatok meghatározott adathalmazzal és várt eredményekkel (pl. bizonylatlánc ajánlattól a jóváírásig, vagy karbantartási megbízás pótalkatrészekkel és időkönyveléssel). Ezek regressziós tesztként vagy ismételhető tesztszkriptekként rögzíthetők.
Fontos: ne csak a sikeres útvonalakat teszteljük, hanem a tipikus hibaútvonalakat is (zárolási ütközések, hiányzó jogosultságok, hiányos törzsadatok, duplikált importfájl).
Automatizálás ott, ahol a legnagyobb hatása van
Nem minden legacy-projektnek kell rögtön 80% unit-teszt lefedettség. A magas ROI gyakran az alábbi területeken jelentkezik:
- domainservice-ek (számítások, szabályok, állapotváltások)
- adat-hozzáférés világos szerződésekkel (mapping, SQL, tranzakciók)
- API-tesztek (auth, jogosultságok, verziózás)
A cél a változások esetén fennálló stabilitás, nem az akadémiai metrikák maximalizálása.
Módszertan a gyakorlatban: egy modernizációs ütemterv
B2B szemszögből a modernizációnak működőképesnek kell maradnia. Egy tipikus, kockázatokhoz igazodó ütemterv:
1. ütem: Analízis, célarchitektúra, gyors nyeremények (2–6 hét)
- Rendszer-térkép (modulok, adatbázisok, interfészek, jobok, függőségek)
- Kockázatmátrix (BDE, harmadik felek, 32/64-Bit, Unicode, deploy)
- A célarchitektúra definiálása (Layer-3, szolgáltatási réteg, API-stratégia)
- Quick Wins: build-folyamat stabilizálása, naplózás javítása, verziókezelés rendbetétele
2. ütem: A szaklogika szétkapcsolása (folyamatos, inkrementális)
- Domainservice-ek azonosítása és kiléptetése a formokból
- Repository-facade-ok bevezetése
- Első regressziós tesztek kritikus use-case-ekhez
3. ütem: Adat-hozzáférés/DB-réteg modernizálása
- FireDAC bevezetése, kapcsolati és tranzakciós koncepció kialakítása
- BDE-Ablösung modulonként (vagy adatbázis-migráció párhuzamos üzemmel)
- Teljesítmény- és zárolási viselkedés terheléses tesztelése
4. ütem: REST-Server és integrációk kiépítése
- API Auth, jogosultságok, verziózás
- Portálok/integrációk csatlakoztatása logika duplikációja nélkül
- Batch- és háttérfolyamatok szolgáltatásainak konszolidálása
5. ütem: Platform- és UI-döntések (64-Bit, ARM64, többplatform)
- 64-Bit build, függőségek cseréje
- ARM64-kompatibilitás ellenőrzése/tervezése
- UI-modernizálás: VCL frissítés vagy FMX/hibrid megoldás, üzleti haszon alapján
A sorrend szándékosan úgy van megválasztva, hogy korán átláthatóságot nyerjenek, aztán a mag stabilizálódjon, és csak ezután terjesszék ki a „látható” változásokat. Így csökken a kockázat, és az üzemeltetés tervezhető marad.
Tipikus anti-patternek: mi drágítja meg feleslegesen a modernizációt
Néhány mintázat auditokban és mentőprojektekben rendszeresen felbukkan:
- „Újraépítjük és csak a feature-öket vesszük át”: szinte mindig logika-vesztéshez vezet, mert kimaradnak a különleges esetek.
- API mint párhuzamos világ: üzleti szabályok a kliensben maradnak, a backendben újra feltalálják őket.
- Adatbázis-csere szemantikai tesztek nélkül: ugyanazok az adatok, de eltérő viselkedés (NULL, rendezés, dátumlogika).
- Túl késői dependency-management: 64-Bit/ARM64 egy kis DLL-en bukik el közvetlenül a Go-Live előtt.
- „Refaktorálás először” célkép nélkül: sok változtatás, kevés mérhető haszon, nagy regressziós rizikó.
A jó ellenpont mindig ugyanaz: előbb célarchitektúra és kockázatok tisztázása, majd inkrementális átépítés, közben a szaklogika tesztelése és láthatóvá tétele.
Következtetés: modernizálni annyi, mint megőrizni — és célzottan bővíteni
Delphi modernizálása anélkül, hogy a szaklogikát elvesztenénk, nem ellentmondás, hanem fegyelmezett munka. A vállalatoknak nem kell választaniuk a „mindent megtartok” és a „mindent lecserélek” között. Tiszta architekturális szeparációval (pl. Layer-3), kontrollált BDE-kiváltással FireDAC irányába, API-stratégiával REST-Servereken keresztül, valamint világos tervvel az Unicode, 64-Bit és új platformok, mint Windows 11 ARM64 kezelésére, egy felhalmozódott rendszert lépésről lépésre át lehet vinni jövőálló struktúrába.
A döntő pont, hogy a szaklogikát mint magvasi vagyont kell kezelni: izolálni, tesztelhetővé tenni, majd modernizálni. Így olyan architektúra jön létre, amely támogatja a portálokat, szolgáltatásokat és a többplatformos követelményeket anélkül, hogy az üzemet veszélyeztetné.
Ha egy Delphi Modernisierung-t tervez, és szeretné szaklogikát, adat-hozzáférést és üzemet tisztán összevezetni, beszéljen velünk egy reális migrációs útról: https://net-base-software-gmbh.de/kontakt/