Daugelis įmonių daugelį metų ar dešimtmečių naudoja stabilias Delphi programas, kurios atvaizduoja jų procesų branduolį: užsakymų apdorojimą, gamybą, aptarnavimą, logistiką, atsiskaitymus, įrenginių valdymą, dokumentų srautus. Šiose sistemose slypi ne tik kodas, bet ir patikimas verslo taisyklių, duomenų modelio, vartotojo vedimo ir eksploatavimo patirties derinys. Būtent tai modernizavimą paverčia sudėtingu: tikroji vertė retai būna vartotojo sąsajoje, dažniau ji glūdi augusioje verslo logikoje.
Jei modernizavimą suprantame kaip „naujo sukūrimą“, tai prarandama yra beveik garantuota. Ne todėl, kad naujos technologijos savaime blogos, bet todėl, kad implicitinė senosios sistemos patirtis – išimtinės situacijos, istoriniai duomenys, procesų išimtys, reguliavimo detalės – perkeliant dažnai visiškai neatsikuria. Rezultatas: brangūs regresijos klaidų taisymai, pasikeitusios proceso trukmės, priėmimo problemos ir projektas, užsitęsiantis ilgiau nei planuota.
Tačiau Delphi labai gerai modernizuojasi neprarandant verslo logikos. Raktas yra kontroliuojamas, etapinis požiūris: pirmiausia sukurti skaidrumą (architektūra, duomenys, rizikos), tada atskirti sluoksnius (UI, duomenų prieiga, domeno logika), vėliau modernizuoti (duomenų bazės tvarkykles, Unicode/64 bitų, API, paslaugas, kelių platformų palaikymą) – tuo pačiu apsaugant veikiančią aplinką. Šiame straipsnyje aprašomi praktiniai modernizavimo modeliai, tipinės kliūtys ir veiksmų eiga, kuri veikia B2B aplinkose su dideliu procesų kritiškumu.
Warum Delphi-Modernisierung selten ein „Technikprojekt“ ist
Praktikoje modernizacijos dažniau žlunga ne dėl trūkstamo kompiliatoriaus parametro, o dėl neteisingų prielaidų apie sistemos elgesį. Delphi programos, plėtotos per daugelį metų, dažnai turi:
- Verslo taisykles GUI įvykiuose (OnClick, OnExit, OnValidate), dažnai paskirstytas per daug formas
- SQL užklausas „arti paviršiaus“, per metus optimizuotas būtent vienai duomenų bazei
- Apėjimus istoriniams duomenims, išimtinėms situacijoms, klientų variantams ar nuomininkų logikai
- Batch procesus, kurie praktiškai vykdomi tam tikruose laikuose ir turi priklausomybių
- Integracijas su ERP, DMS, CRM ar įrenginiais, kurios beveik nėra dokumentuotos
- Tylų žinojimą operacijų rutinoje: „Jei klaida X, tada pirmiausia patikrinti Y“
Pradedant „Big-Bang“-perrašymą, visa ši patirtis turi būti atkurta iš naujo – įskaitant klaidas, kurių senoji sistema jau seniai nebedaro. Geresnis požiūris yra traktuoti verslo logiką kaip vertybę: pirmiausia izoliuoti, tada apsaugoti, tada modernizuoti.
Modernisierung ohne Logikverlust: Zielbild und Leitprinzipien
Tvari tikslinė vizija B2B sistemoms nėra „viskas nauja“, o architektūra, kuri leidžia keistis. Tipinės savybės:
- Atskirtos atsakomybės (UI, domenas/verslo logika, duomenų prieiga, integracijos)
- Testavimas ir matavimas (regresijos testai, logging, monitoringas, reproducible builds)
- Etapinis keičiamumas (UI modernizuoti, neperkurus duomenų modelio; DB migruoti, neperrašant UI)
- API gebėjimas (REST-Server arba paslaugų sluoksnis, skirtas portalams, mobiliems sprendimams ir integracijoms)
- Operacinis pasiruošimas (Windows- ir Linux-services, aiškūs deploymentai, rollback strategija)
Delphi atveju tai ypač pasiekiama, nes galite pernaudoti esamas unidades ir domeno klases ir tuo pačiu modernizuoti aplinką: duomenų prieiga nuo BDE prie BDE-Ablösung mit nativer Anbindung, nauji REST endpointai, nauji UI moduliai, nauji deploymentai.
Bestandsaufnahme: Was muss wirklich erhalten bleiben?
Prieš pradedant „liesti“ kodą verta atlikti struktūruotą inventorizaciją. Tikslas nėra pilna dokumentacija, o patikima sprendimų priėmimo bazė.
1) Fachlogik-Landkarte statt Code-Lesemarathon
Praktiškai pasiteisina verslo logikos žemėlapis su šiomis perspektyvomis:
- Use-Cases: Kokie esminiai procesai yra verslui kritiški? (pvz., užsakymo sukūrimas, sąskaita, stornas, grąžinimas, įrenginių aptarnavimas, priežiūros sutartis)
- Regeln: Kokie validavimai, skaičiavimai, būsenų automatai egzistuoja?
- Varianten: Nuomininkai, klientų konfigūracijos, šalių specifinės taisyklės
- Schnittstellen: Importas/eksportas, ERP/DMS/CRM, įrenginiai/protokolai
- Batch/Jobs: naktiniai paleidimai, ataskaitos, duomenų sinchronizacijos
Iš šio žemėlapio susidaro prioritetizuoti modernizacijos paketai: kas turi likti stabili, kas gali keistis, kas gali būti atidėta vėlesniam etapui.
2) Technische Schulden sichtbar machen
Tipinės techninės skolos senesnėse Delphi sistemose:
- Borland BDE/Paradox priklausomybės
- ANSI eilutės/nebuvusi Unicode migracija
- 32-bit tik, pasenę trečiųjų šalių komponentai
- Monolitinė formų logika, globalūs kintamieji, vienapusiais poveikiais pasižyminčios unit’ai
- Neaiškios transakcijų ribos ir „SQL visur“
Menas yra šiuos punktus ne dogmatiškai „išvalyti“, o sudėlioti prioritetų tvarka, kuri minimizuoja riziką ir maksimalizuoja verslo vertę.
Architektur-Entkopplung: Der Hebel gegen Logikverlust
Dažniausia logikos praradimo priežastis yra UI, duomenų prieigos ir verslo taisyklių susimaišymas. Modernizavimas todėl prasideda nuo atsiejimo – ne nuo „naujo UI framework“.
Layer-3 Architektur als pragmatischer Zielzustand
Daugeliui Delphi legacy programų gerai veikia Layer-3 Architektur:
- Presentation Layer: VCL/FMX formos, ViewModeliai/Presenteriai, validacija tik UI-lygiu (formatas, privalomi laukai)
- Business Layer: domeno modeliai, paslaugos, taisyklės, būsenų logika, skaičiavimai
- Data/Integration Layer: repository, SQL/ORM dalys, sąsajų adapteriai, REST klientai, messaging
Privalumas: verslo logika tampa testuojama ir pakartotinai naudojama. Vėliau klientų portalas, REST-Server ar Linux paslauga gali tiksliai naudoti tuos pačius domeno servisus. Taip modernizuojate „išorinį sluoksnį“, neperręsdami branduolinės logikos.
Strangulation Pattern: Altes System schrittweise „umarmen“
Patikrintas migracijos modelis yra Strangulation Pattern: naujos funkcijos kuriamos jau naujoje struktūroje (pvz., domeno servisas + repository), tuo tarpu esamos formos nuosekliai rekonstruojamos. Sena sistema lieka veikianti, bet ji dalimis keičiama naujomis dalimis.
Svarbu aktyviai pakeisti priklausomybes: ne „forma kviečia SQL“, o „forma kviečia servisą“, o servisas priima sprendimą. Ši nedidelė inversija dažnai suteikia didžiausią naudą.
Datenzugriff modernisieren: BDE-Ablösung und FireDAC sauber planen
Viena esminių modernizacijos dalių yra BDE-Ablösung. Įmonės dažnai nuvertina, kad tai ne tik tvarkyklės keitimas, o SQL semantika, transakcijos, lockingas, duomenų tipai ir klaidų elgesys. Modernūs Delphi stack’ai dažniausiai remiasi BDE-Ablosung mit nativer Anbindung su natyviomis tvarkyklėmis (pvz., MariaDB/MySQL, PostgreSQL, SQL Server).
Was bei der Umstellung wirklich entschieden wird
- Duomenų bazės tikslas: Ar liekate prie esamos DB? Ar prasmingas duomenų bazės pertvarkymas (pvz., iš Paradox/Firebird į MariaDB arba PostgreSQL)?
- Transakcijų modelis: Kur prasideda/baigiasi transakcijos? Kokie use-case’ai turi būti atomariniai?
- Konkurencija/locking: optimistinis vs. pesimistinis, deadlockų valdymas, retry strategijos
- SQL dialektas: datų funkcijos, eilutės elgsena, NULL tvarkymas, didžiųjų/mažųjų raidžių jautrumas
- Veikimas: indeksai, užklausų planai, puslapiavimas, masiniai įrašai
Verslo logika glaudžiai susijusi su duomenų elgesiu. Jei duomenų migracija daroma „šalia“, rizikuojama subtiliomis neatitikimų praktinėmis pasekmėmis: suapvalinimai, rikiavimas, datų ribos, užrakinimo konfliktai. Todėl duomenų lygmuo turi būti įtrauktas anksti į modernizacijos planą, įskaitant migracijos kelią ir testinių duomenų strategiją.
Pragmatische Schritte zur FireDAC-Migration
Užuot visą programą vienu metu pertvarkius, sekanti eiliškumo tvarka pasiteisino praktikoje:
- Įdiegti duomenų prieigos sluoksnį (Repository/DAO) kaip fasadą
- Perjungti atskirus use-case’us prie FireDAC (pvz., pirmiausia „skaitymas“, vėliau „rašymas“)
- Suvienodinti connection handling, klaidų valdymą, loggingą
- Etapinis BDE komponentų išjungimas ten, kur fasada yra stabili
Taip programa išlieka bet kada pristatoma, ir išvengsite ilgo tarpo, kai „viskas pusiau baigta“.
Unicode, 64-Bit und Abhängigkeiten: Die Modernisierungsfallen im Detail
Daugelis modernizacijų nepasiseka ne dėl koncepcijos, o dėl nuvertinamų smulkmenų. Trys tokie dažni klausimai Delphi projektuose:
Unicode-Migration: Nicht nur Strings, sondern Datenflüsse
Labai senose Delphi versijose sistemos kilo iš ANSI pasaulio. Unicode migracija tuomet apima:
- Eilutės tipus ir konvertacijas (WideString/AnsiString/UnicodeString)
- Failų ir kelių tvarkymą (Windows API, tinklo keliai)
- Importą/eksportą (CSV, fiksuoto ilgio laukai, EDI, legacy sąsajos)
- Rikiavimą/koliaciją duomenų bazėje
Svarbu identifikuoti kritinius duomenų srautus (pvz., sąskaitų tekstai, prekių pavadinimai, tarptautiniai adresai) ir sukurti regresijos testus. Unicode yra ne vien „pertvarkymas“, o nuoseklus kokybės procesas.
64-Bit Umstieg: Speicher ist nicht das einzige Thema
64-bitų migracija dažnai suvokiama kaip „tik rodyklių dydžiai“. Praktikoje dažniau tai reiškia:
- Pasenusios trečiųjų šalių bibliotekos be 64-bit palaikymo
- COM/ActiveX priklausomybės
- DLL ir tvarkyklės (brūkšninių kodų skaitytuvai, įrenginiai, kriptografija, parašai)
- Installer/Deployment ir registro keliai (WOW64)
Pragmatiška strategija – pirmiausia inventorizuoti visas išorines priklausomybes ir apibrėžti alternatyvas. Tada 64-bit žingsnis suplanuojamas – ir nebekyla staigmenų prieš išleidimą.
Windows 11 ARM64: Früh prüfen statt spät bezahlen
Su Windows 11 ARM64 atsiranda nauja tikslinių sistemų klasė. Nors ne kiekviena įmonė iš karto reikalaus natyvių ARM64 build’ų, protinga anksti patikrinti:
- Ar yra natyvių priklausomybių (DLL, tvarkyklės), kurios neveiks ARM64?
- Ar programa priklauso nuo emuliacijos ir ar tai priimtina?
- Koks installerio elgesys, kaip vykdomi update/repair?
Modernizacijos projektuose tai dažnai tampa „vėlyvu“ klausimu, kuris brangiai kainuoja. Geriau: anksti įtraukti į platformos roadmap’ą ir techninį patikrinimą.
REST-Server und Services: Fachlogik für Portale und Integration nutzbar machen
Daugelis įmonių modernizuoja Delphi ne dėl to, kad darbalaukio programa atrodo pasenusi, o dėl naujų reikalavimų: klientų portalas, partnerių prieigos, mobilūs procesai, integracija su ERP/DMS/CRM, ataskaitų pipeline’ai. Tam reikia aiškių sąsajų. REST-serveris dažnai yra praktiškiausia tilto vieta.
API zuerst? Nur, wenn Rechte und Domänenlogik mitkommen
API yra naudinga tik tada, kai ji taiko tą pačią verslo logiką, kaip klientas. Kitu atveju susiformuoja du taisyklių rinkiniai: vienas darbalaukyje, kitas backend’e. Pasekmės – neatitikimai ir saugumo spragos.
Dėl to REST-serverio sluoksnis turėtų kuo tiesiogiau remtis domeno servisais. Tipiniai komponentai:
- Autentifikacija/autorizacija (rolės, nuomininkai, teisės)
- DTOs/serializacija su aiškiomis versijavimo taisyklėmis
- Transakcijų ir klaidų koncepcija (HTTP statusai, Problem-Details, loggingas)
- Idempotencija ir lygiagretiškumas (retry, eilių apdorojimas)
Taip REST-serveris tampa stabilus integracijos taškas – ne „antru klientu“.
Linux-Services und Windows Services modernisieren
Batch procesai ir integracijos daugelyje įmonių veikia kaip Windows servisos, Task Scheduler darbai ar net „paslėptos“ darbalaukio instancijos. Modernizuojant verta konsoliduoti:
- Atskyrimas tarp UI ir fono logikos
- Konfigūruojami vykdymo grafikai ir aiškūs eksploatavimo parametrai
- Tvarkingas loggingas (struktūruoti logai, koreliacija pagal darbą/užklausą)
- Galimybė vykdyti paslaugas kaip Linux (pvz., konteinerizuoti deploymentai)
Prietaisas duoda ne tik „modernumą“, bet ir operacinį privalumą: reproducuojamas veikimas, mažiau rankinių intervencijų, geresnė klaidų diagnostika.
UI modernisieren, ohne den Kern anzufassen: VCL, FMX und hybride Ansätze
Daugelis modernizacijos planų prasideda nuo UI. Tai gali būti prasminga – jei aišku, ką iš to gaunama. Kai verslo logika yra atskirta, UI galima atnaujinti su mažesne rizika.
VCL-Anwendungen schrittweise modernisieren
VCL daugelyje B2B scenarijų vis dar yra tvirtas pasirinkimas, ypač aplinkose su intensyviu Windows naudojimu ir dideliu darbalaukio produktyvumu. Modernizacija čia gali reikšti:
- UI logikos mažinimą (Presenter/ViewModel), verslo taisyklių perkėlimą į servisus
- Komponentų kraštovaizdžio išvalymą, nuosavų valdiklių konsolidavimą
- Atsako/naudojimo patirties gerinimą (Async, fono darbai, progress, Cancel)
- Prieinamumo gerinimą, nuoseklią validaciją, aiškesnes klaidų žinutes
Tai suteikia akivaizdžią vertę be visos sąsajos perrašymo.
Delphi Multiplattform: Wann FMX Sinn ergibt
Jei egzistuoja tikros kelių platformų reikalavimai (Windows, macOS, galbūt Linux paslaugų kontekste), FMX gali būti pasirinkimas.Svarbu lūkesčiai: kelių platformų sprendimas reiškia papildomą testavimo ir integracijos darbą (fontai, spausdinimas, OS dialogai, failų sistema, pakavimas/deployment). Išlaidos yra gerai apibrėžiamos, jei verslo logika jau yra tvarkingame sluoksnyje.
Dažnas pragmatiškas kelias yra hibridas: VCL lieka Windows klientui, o nauji frontend’ai (portalas, mobilioji aplikacija) prijungiami per REST-serverį. Taip kelioms platformoms pritaikoma per sistemos ribas, o ne per vieną UI stack’ą.
Testing und Regression: Wie man Fachlogik „festnagelt“
„Prarasti verslo logiką“ praktiškai reiškia: sistema kraštinėse situacijose duoda kitus rezultatus. Tai retai matoma iš karto, bet brangu. Todėl testavimo gebėjimas nėra prabanga, o modernizacijos įrankis.
Goldene Use-Cases und Referenzdaten
Pasiteisina „auksinių“ use-case’ų rinkinys: realūs, kritiniai procesai su apibrėžta duomenų būsena ir lauktinais rezultatais (pvz., dokumentų grandinė nuo pasiūlymo iki kredito, arba techninio aptarnavimo užsakymas su atsarginėmis dalimis ir laiko įrašais). Šie atvejai tampa regresijos testais arba pakartojamais testų skriptais.
Svarbu: ne tik sėkmės keliai, bet ir tipiniai klaidų keliai (užrakinimo konfliktai, trūkstamos teisės, nevisiški master duomenys, dvigubi importo failai).
Automatisierung dort, wo sie den größten Hebel hat
Ne kiekvienam legacy projektui iš karto reikia 80 % unit testų dengimo. Didžiausią ROI dažnai duoda:
- Domeno servisai (skaičiavimai, taisyklės, būsenų pakeitimai)
- Duomenų prieiga su aiškiais kontraktais (mappings, SQL, transakcijos)
- API testai (autentifikacija, teisės, versijavimas)
Tikslas yra stabilumas keičiant, o ne akademiniai metrikų rodikliai.
Vorgehensmodell in der Praxis: Ein Modernisierungsfahrplan in Etappen
Iš B2B perspektyvos modernizacija turi išlikti pristatoma. Tipinis žingsnių planas, orientuotas į rizikas:
Etappe 1: Analyse, Zielarchitektur, Quick Wins (2–6 Wochen)
- Sistemos žemėlapis (moduliai, duomenų bazės, sąsajos, darbai, priklausomybės)
- Rizikos matrica (BDE, trečiųjų šalių komponentai, 32/64 bit, Unicode, deployment)
- Tikslinės architektūros apibrėžimas (Layer-3, paslaugų sluoksnis, API strategija)
- Quick Wins: build proceso stabilizavimas, loggingo gerinimas, versijų valdymo sutvarkymas
Etappe 2: Entkopplung der Fachlogik (laufend, inkrementell)
- Identifikuoti domeno servisus ir juos iškelti iš formų
- Įdiegti repository fasadas
- Pirmieji regresijos testai kritiniams use-case’ams
Etappe 3: Datenzugriff/DB-Schicht modernisieren
- Įdiegti FireDAC, apibrėžti ryšio ir transakcijų koncepciją
- BDE-Ablösung modulais (arba duomenų bazės migracija su paraleliniu veikimu)
- Veikimo ir užrakinimo elgesio testavimas apkrovos sąlygomis
Etappe 4: REST-Server und Integrationen nachrüsten
- API su autentifikacija, teisėmis, versijavimu
- Portalai/integracijos prijungiamos, neįvedant dvigubos logikos
- Paslaugos batch ir foniniams procesams konsoliduojamos
Etappe 5: Plattform und UI-Entscheidungen (64-Bit, ARM64, Multiplattform)
- 64-Bit build, priklausomybių pakeitimas
- ARM64 suderinamumo patikrinimas/planavimas
- UI modernizacija: VCL atnaujinimas arba FMX/hibridinis sprendimas, remiantis verslo nauda
Eiliškumas parinktas taip, kad anksti gautumėte skaidrumą, vėliau stabilizuotumėte branduolį ir tik po to plačiai diegtumėte matomus pokyčius. Taip sumažėja rizika ir eksploatacija lieka planuojama.
Typische Anti-Patterns: Was Modernisierungen unnötig teuer macht
Auditų ir gelbėjimo projektų metu pasikartojantys modeliai:
- „Wir bauen neu und übernehmen nur Features“: beveik visada veda į verslo logikos praradimą, nes trūksta išimčių.
- API als Parallelwelt: verslo taisyklės lieka kliente ir backend’e yra sukuriamos iš naujo.
- Datenbankwechsel ohne Semantiktests: tie patys duomenys, bet skirtingas elgesys (NULL, rikiavimas, datų logika).
- Zu spätes Dependency-Management: 64-Bit/ARM64 žlunga dėl mažos DLL likus prieš paleidimą.
- „Refactoring zuerst“ ohne Zielbild: daug pakeitimų, mažai matomo naudos, didelė regresijos rizika.
Priešnuodis visuomet vienas: pirmiausia aiškus tikslinės architektūros ir rizikų apibrėžimas, tada inkrementinis pertvarkymas, tuo pačiu testuojant ir darant verslo logiką matomą.
Fazit: Modernisieren heißt bewahren – und gezielt erweitern
Delphi modernizuoti neprarandant verslo logikos nėra prieštara, o disciplina. Įmonėms nereikia rinktis tarp „viską išlaikyti“ ir „viską pakeisti“. Su aiškia architektūros separacija (pvz., Layer-3), kontroliuojama BDE-Ablösung link FireDAC, API strategija per REST-serverį bei aiškus planas Unicode, 64-Bit ir naujoms platformoms kaip Windows 11 ARM64 – augusią sistemą galima etapais perkelti į ateičiai tinkamą struktūrą.
Svarbiausia elgtis su verslo logika kaip su branduoliniu turtu: izoliuoti, padaryti testuojamą, tada modernizuoti. Taip susiformuoja architektūra, kuri palaiko portalus, paslaugas ir kelių platformų reikalavimus, nekeliančią rizikos veikiančiai aplinkai.
Jei planuojate Delphi Modernisierung ir norite tinkamai sujungti verslo logiką, duomenų prieigą ir eksploatavimą, susisiekite su mumis dėl realaus migracijos kelio: https://net-base-software-gmbh.de/kontakt/