Delphi korszerűsítése anélkül, hogy az üzleti logika elveszne.

Delphi-alkalmazások sok vállalatnál évek óta stabilan futnak – és pontosan azt a szakmai logikát valósítják meg, amely biztosítja a bevételt, a szolgáltatásminőséget és a megfelelőséget. Egy modernizálás ezért ritkán „új felületről” szól, sokkal inkább egy kontrollált továbbfejlesztésről, amely során megőrződnek a szabályok, az eseti kivételek és a történeti folyamatismeret.

Ebben a cikkben bemutatunk egy gyakorlatban bevált eljárást, amellyel lépésről lépésre lehet modernizálni a Delphi-t: az állapotfelméréstől az UI/adathozzáférés szétválasztásán át a technikai modernizációig (Unicode/64‑Bit, BDE-kiváltás, API/szolgáltatások) – beleértve a tesztekkel, monitoringgal és párhuzamos üzemmel történő biztosítást. A cél egy modernizálható architektúra, Big-Bang-rewrite és logikaveszteség nélkül.

A modernizációk a gyakorlatban ritkán a kompilátor vagy egy framework miatt buknak el; sokkal inkább a rendszer viselkedésére vonatkozó helytelen feltételezások miatt. Évek alatt felhalmozódott Delphi-alkalmazások tipikusan tartalmaznak szakmai szabályokat GUI-eseményekben, SQL-t űrlaplogikában, ügyfél/mandáns szerinti variánsokat, történeti okokból adódó kivételeket, valamint integrációkat, amelyek csak „üzem közben” vannak dokumentálva.

Egy Big-Bang-rewrite arra kényszerít, hogy ezt a tudást újra rekonstruáljuk – beleértve azokat a hibákat is, amelyeket az altrendszer már régen nem produkál. Jobb megközelítés a szakmai logikát vagyoni értékként kezelni: izolálni, biztosítani, majd lépésről lépésre modernizálni.

Egy fenntartható célkép a folyamatkritikus B2B rendszerek számára nem az, hogy „minden újat”, hanem olyan architektúra, amely lehetővé teszi a változtatásokat anélkül, hogy veszélyeztetné a működő üzemet:

• egyértelmű elkülönítés a UI, a doménlogika, az adathozzáférés és az integrációk között
• tesztelhetőség és mérhetőség (regresszió, naplózás, monitoring, reprodukálható build-ek)
• lépcsőzetes kicserélhetőség (UI modernizálása azonnali adatbázis-migráció nélkül – vagy fordítva)
• API-képesség (pl. REST), portálok, mobil megoldások vagy rendszerintegrációk csatlakoztatásához
• üzemképes telepítések rollback-opcióval

Delphi erre jól alkalmas, mert a meglévő unitok és doménosztályok továbbhasználhatók, miközben a környezet körül modernizálódik.

Mielőtt a kódot módosítanák, megbízható döntési alapra van szükség – nem teljes dokumentációra. Bevált három eredmény:

• Üzleti logika-térkép: kritikus use-case-ek, szabályok/számítások, variánsok (mandánsok/országok/ügyfelek), interfészek, feladatok/batch-futtatások.
• Kockázati profil: különösen hibára érzékeny területek, adatok minősége, szabályozói követelmények, üzem közbeni szűk keresztmetszetek (teljesítmény, stabilitás, karbantarthatóság).
• Modernizációs backlog: priorizált csomagok üzleti érték és kockázat szerint (mi maradjon stabil, mi változhat, mi halasztható).

Ez lehetővé teszi, hogy a modernizáció tervezhető legyen: egyértelmű inkrementumokkal ahelyett, hogy egyetlen „minden-vagy-semmi” projektbe kényszerülnénk.

Ahhoz, hogy az üzleti logika ne változzon „véletlenül”, szükség van egy olyan biztosításra, amely független a UI-refaktorálástól. Tipikus építőkövek:

• Characterization/Golden-Master-teszt(ek): a meglévő viselkedés reprezentatív bemenet/kimenet párokkal rögzítésre kerül (jelentések, számítások, folyamatlépések).
• Regressziós tesztek use-case szinten: az üzletileg kritikus folyamatok automatizáltan vagy félautomatikusan reprodukálhatók.
• Telemetry: naplózás, metrikák és hibaképek a változtatás előtt/után összehasonlíthatóvá válnak.
• Párhuzamos üzem & kontrollált átállás: az új modulok a meglévő mellett futnak (feature toggle-ok, pilotcsoportok), egyértelmű rollback-stratégiával.

Csak akkor érdemes a tényleges technikai modernizációba kezdeni, ha ezek a biztonsági hálók rendelkezésre állnak – mert így a kockázat és az utómunka drámaian csökken.

A logika elvesztésének leggyakoribb oka az UI, az adatelérés és az üzleti szabályok összekeveredése. A modernizálás ezért az elválasztással kezdődik – nem az UI-keretrendszer cseréjével.

A pragmatikus cél egy 3 rétegű struktúra:

• Presentation: VCL/FMX, Presenter/ViewModel, csak UI-közeli érvényesítés (formátum, kötelező mezők)
• Business: doménamodellek, szolgáltatások, szabályok, állapotlogika, számítások
• Data/Integration: Repositories, adatbázis-hozzáférés, adapterek ERP/DMS/CRM-hez, REST-Clients, Messaging

Gyakorlati szabály: Az üzleti szabályok kikerülnek az OnClick/OnExit eseményekből a doménszolgáltatásokba. SQL kikerül a Forms-ból a Repositories-be. Így a logika tesztelhetővé válik és később az UI, Services és Jobs által újrahasznosítható.

A Strangulation Pattern esetén az újat tudatosan a meglévő mellett hozzuk létre: az új funkciók már az elválasztott struktúrában implementálódnak, miközben az Altsystem tovább fut. Lépésről lépésre az új réteg egyre több felelősséget vesz át, míg a régi részek elmaradnak.

Példa (tipikus B2B):

• Kivonják a megrendelés logikáját egy doménszolgáltatásba.
• A meglévő VCL-UI kezdetben ugyanazt a Service-t használja (kein Prozessbruch).
• Párhuzamosan létrejön egy REST-Endpunkt egy ügyfélportálhoz vagy egy integrációhoz.
• A stabilizálást követően egyes régi Forms-okat leváltanak – anélkül, hogy a maglogikát újra kellene építeni.

Így csökkentik a projektkockázatot, megőrzik az üzemképességet és gyorsan mérhető hasznot érnek el (pl. API, teljesítmény, karbantarthatóság).

A kiindulási helyzettől függően ezek az építőelemek gyakran relevánsak – döntő a kockázat és az üzleti érték szerinti prioritás:

• BDE/Legacy-DB-hozzáférés kiváltása: modern illesztőprogramok/Provider-ek, tiszta tranzakciós határok, reprodukálható telepítések.
• Unicode: karakterlánc-kezelés, adatbázis/interfészek, harmadik fél komponensei.
• 64‑Bit: függőségek, memória/teljesítmény, külső Libraries.
• API- und Service-Schicht: REST, Windows-/Linux-Services, integrációk.
• Build & Release: CI/CD, artefaktmanagement, aláírt installer-ek, Rollback.

Fontos: ezeket a pontokat ideálisan után az elválasztás és az biztosítás után kell végrehajtani – így a változtatások biztonságosan verifikálhatók.

Egy teljes Rewrite bizonyos esetekben indokolt – gyakran azonban ez a legdrágább út, hogy „moderne Technik”-et kapjunk. Ezek a kérdések segítenek a besorolásban:

• Az üzleti logika teljes mértékben megértett és tesztelhető – vagy sok tudás implicit módon a működésben van?
• Vannak-e szigorú határidők (pl. Plattform-Ende, Compliance), amelyek kizárják a párhuzamos üzemet?
• Mekkora a variánsok sokfélesége (Kunden-/Mandantenlogik)?
• Mennyire kritikus a rendelkezésre állás, és milyen a tolerancia a folyamatváltozásokra?
• Mely részek a valódi „felelősek” (UI, adathozzáférés, integrációk, Deployment) – és melyek stabilak?

Sok B2B-s forgatókönyvben a lépésenkénti megközelítés gyorsabban vezet mérhető eredményekhez, mert kontrollálja a kockázatokat és védi az üzleti logikát.

Delphi-Modernisierungs-Audit (folyamatkritikus alkalmazásokhoz): Elemezzük az architektúrát, a függőségeket, a kockázati területeket és egy prioritizált roadmapet adunk arra, hogyan modernizálhat anélkül, hogy az üzleti logikát elveszítené.

• Bemenet: kódbázis (read-only), Build-Setup, 2–3 kulcs-Use-Cases, rendszerkörnyezet (DB, integrációk).
• Eredmény: üzleti logika-/modul-térkép, kockázat- és függőség-elemzés, ajánlott célarchitektúra, végrehajtási terv inkrementekben, beleértve a kockázatcsökkentő intézkedéseket (tesztek/párhuzamos üzem).
• Opcionális: Proof of Concept a leválasztáshoz + első Golden-Master-teszt.

Így megbízható döntési alapot kap, mielőtt költségvetést és időt egy kockázatos újraírásba fektetne.

Lehet-e Delphi modernizálni anélkül, hogy az alkalmazást újraírnák?
Igen. Sok esetben először az üzleti logikát és az adat-hozzáférést választják szét, majd technikailag modernizálják. Ez csökkenti a kockázatot és stabilan tartja az üzemeltetést.

Hogyan lehet megakadályozni, hogy az üzleti logikát „csendben” megváltoztassák?
Golden-Master-/regressziós tesztekkel, telemetriával, valamint szabályozott párhuzamos üzemben alkalmazott, egyértelmű visszagörgetési stratégiával.

Mely lépések hoznak gyakran a leggyorsabb hasznot?
Átláthatóság (assessment), az UI/SQL leválasztása, BDE kiváltása és egy API-/szolgáltatásréteg az integrációkhoz – mindegyiket tesztek biztosítják.

Mennyi ideig tart egy modernizáció?
Ez függ a kritikus használati esetektől, a variánsok sokféleségétől és a függőségektől. Egy audit rendszerint rövid idő alatt megbízható ütemtervet és priorizált inkrementeket ad.