C# i Delphi u zajedničkoj arhitekturi: pragmatična integracija umjesto pristupa ili-ili

U mnogim IT-odjelima početna je situacija slična: stabilna, usko vezana uz procese Delphi-desktop aplikacija podržava kritične procese, dok se novi zahtjevi usmjeravaju prema webu, portalima, mobilnoj upotrebi i integraciji s cloud-uslugama. Istovremeno je C# u mnogim tvrtkama utvrđen kad se radi o servisima, web-API-jima i integraciji identiteta. Stoga glavno pitanje više nije „Delphi oder C#?“, nego: C# und Delphi in einer gemeinsamen Architektur tako kombinirati da operacije, održavanje, pohrana podataka i sigurnost ostanu pod kontrolom.

Ovaj članak opisuje primjenjiva arhitektonska načela koja se dokazuju u korporativnim okruženjima u kojima se ne može ili ne smije sve graditi iznova. Fokus je na jasnim odgovornostima između desktop-klijenta, servisa, podataka i sučelja – i na tome kako planirati korake modernizacije s niskim rizikom, bez ugrožavanja tekućih procesa.

Warum gemischte Stacks in Unternehmen normal sind

Rasli digitalni poslovni sustavi rijetko nastaju „na zelenom polju“. Delphi-aplikacije često su se tijekom godina proširivale, blizu poslovnih procesa, s opsežnom logikom podataka i dubokim znanjem o posebnim slučajevima. Paralelno su nastali novi zahtjevi: self-service portali, automatizirane razmjene podataka, povezivanje DMS/CRM/ERP sustava, podrška za više najmoprimaca, povećana auditabilnost ili Single Sign-on.

C# u tom kontekstu često nudi prednosti za web- i servisne ekosustave: širok spektar hostinga, standardizirana middleware, dobra integracija s identity providerima i etablirani obrasci za web-API-je. Delphi ostaje snažan kada je riječ o visoko-performantnim Windows-desktop-klijentima, dugoročno održavanim VCL-aplikacijama ili specifičnim multiplatformskim klijentima (npr. preko FMX).

Zbog toga mješavina nije „Sonderfall“, nego realan odgovor na zaštitu ulaganja i pritisak modernizacije. Ključno je da zajednički rad ne postane stalno gradilište.

Architekturgrundsatz: klare Schichten statt Sprachgrenzen

Kada se spoje dva jezika/tehnologije, velika je napast organizirati razdvajanje prema tehnologiji („Sve Delphi je naslijeđeno, sve C# je novo“). Tehnički to često kratkoročno funkcionira, ali dugoročno vodi do trenja: dupliciranih poslovnih pravila, nejasnih odgovornosti i teško reproducibilnih pogrešaka.

Umjesto toga pokazala se učinkovita funkcionalna višeslojnost, često realizirana kao Layer-3 Architektur: prezentacija (UI), domena (poslovna logika) i infrastruktura (pristup podacima, vanjski sustavi). Bit nije toliko u udžbeničkom modelu, koliko u konkretnoj učinkovitosti u praksi: odluke o podacima, validacijama i radnim tokovima donose se na jednom mjestu i izlažu preko stabilnih sučelja.

U miješanoj arhitekturi to praktično znači: Delphi i dalje može isporučivati UI-dio (ili određene tokove rada), dok C# Services enkapsuliraju funkcionalnu domensku razinu – ili obrnuto. Važno je da je granica između slojeva tehnički jasno definirana i testabilna.

C# und Delphi in einer gemeinsamen Architektur: drei bewährte Integrationsmuster

Za povezivanje Delphi i C# ne postoji „jedan“ ispravan put. Dobre odluke temelje se na radu u produkciji, sigurnosnim zahtjevima, latenciji, volumenu podataka i ciklusima izdanja. U praksi su se pokazala tri obrasca.

1) Servisna orijentacija preko HTTP/REST kao standardna integracija

Za operativni rad i daljnji razvoj najrobustnije je povezivanje putem REST-API-ja (HTTP-bazirana sučelja). Delphi-klijenti pozivaju C#- ili Delphi-servise; C#-portali koriste iste krajnje točke. Ovo razdvajanje čini izdanja lakše za planiranje: ažuriranje klijenta nije nužno ako API ostane unatrag kompatibilan.

Važno je profesionalno oblikovanje: timeouti, retryi, idempotencija (ponovljivi zahtjevi bez nuspojava), jasni kodovi pogrešaka i strategija verzioniranja. Za administraciju i operacije dodatno je važno: jedinstveni logovi, reproducibilne Request-ID-e i dobro mjerljiva vremena odziva.

2) Zajednička baza podataka: samo uz jasna pravila

Zajednički pristup bazi podataka od strane Delphi i C# djeluje primamljivo jer je u početku brz. Dugoročno je međutim rizičan ako oba sustava izravno pišu u iste tablice. Razlog: poslovna pravila migriraju u okidače, spremljene procedure ili „negdje u klijent“. To otežava analizu pogrešaka i revizije.

Ako je zajednička baza neizbježna (npr. u prijelaznim fazama), pomažu jasna pravila:

• Središnite pisanja: jedan sustav je „System of Record“ za određene entitete.
• Definirajte ugovore: view-ovi ili API-ji kao stabilni sloj za čitanje umjesto izravnih pristupa tablicama.
• Planirajte prozore za migracije: promjene u bazi podataka uvijek uvesti unatrag kompatibilno (npr. nove kolone najprije kao opcionalne).

Tehnički je baza tada infrastrukturna komponenta, a ne integracijski autobus.

3) Messaging/Events za asinkrone procese

Za odvojene tokove (npr. importi, obavijesti, naknadna obrada, jobs za sučelja) smislen je asinkroni model: jedan sustav objavljuje događaje, drugi ih obrađuje. To smanjuje izravne ovisnosti i stabilizira vršne opterećenja.

Za IT-upravu i administratore važno je: monitoring (duljine redova), koncepti dead-letter-a (neuspjele poruke), ponašanje pri ponovnom pokretanju i jasna poslovna idempotencija. Events nisu zamjena za uredno upravljanje matičnim podacima, ali su dobar alat za robusne procesne lance.

Ugovori o podacima i kompatibilnost: podcijenjena srž

Neovisno o obrascu integracije, kvalitet ugovora o podacima određuje stabilnost. Ugovor o podacima je obvezujući opis polja, tipova, obvezno/izborno i semantike. U REST-API-jima to je tipično JSON; važno nije „JSON sam po sebi“, nego disciplina u postupanju s promjenama.

Provjerena pravila koja značajno pojednostavljuju rad:

• Proširivati umjesto prekidati: dodavati nova polja, stare polja u početku i dalje isporučivati.
• Dokumentirati semantiku polja: ne samo „string“, nego npr. ISO-datum, vremenska zona, dozvoljena stanja.
• Tretirati enum-vrijednosti tolerantno: klijenti moraju preživjeti nepoznate vrijednosti (kompatibilnost prema naprijed).
• Svjesno koristiti verzioniranje API-ja: ne svako izdanje zahtijeva novu verziju; ali breaking changes (nekompatibilne promjene) moraju biti jasno kapsulirane.

Ove točke su posebno važne kada Delphi-desktop-klijenti ne mogu biti ažurirani tako često kao web-servisi.

Autentikacija i autorizacija: zajednički sigurnosni model

Hibridne arhitekture rijetko propadaju zbog „tehnike“, češće zbog nedosljedne sigurnosti. Za poduzeća je odlučujuće: tko smije što? Kako se to provjerava? Kako se to auditira? Zajednički model izbjegava dvostruku upravu korisnicima i kontradiktorne uloge.

U praksi to vodi do centralnog sloja identiteta: npr. preko SAML 2.0 (federirano Single Sign-on, često u Enterprise okruženju) ili OpenID Connect (baziran na OAuth2, često za moderne web-API-je). C#-servise obično je moguće direktno povezati na Identity Provider; Delphi-klijenti mogu dobivati tokene i slati ih pri API-pozivima. Važno je da ni desktop-aplikacije nemaju „posebna prava“ putem izravnog pristupa bazi podataka.

Za administratore ključno:

• Vrijeme trajanja tokena i strategija osvježavanja (kako bi klijenti radili stabilno, a ipak bili sigurni)
• Autentikacija između servisa za internu komunikaciju (npr. mTLS ili potpisani tokeni)
• Princip najmanjih privilegija: uloge i dozvole ne smiju biti pregrubo definirane
• Audit-Logs: sigurnosno relevantne akcije dokumentirati tako da su provjerljive

Operativni koncepti: Windows- und Linux-Services, IIS und Prozesse im Alltag

Arhitektura je u poduzeću dobra samo ako je održiva: ažuriranja planirana, pogreške lokalizirane, opterećenje pod kontrolom. U hibridnim okruženjima najčešće varijante operacije su:

• Windows- und Linux-Services: pogodna za pozadinske zadatke, izvođenje sučelja, workere; dobro se integriraju u klasične Windows-server modele rada.
• Windows- und Linux-Services/Daemon: smisleno za kontejnerizirane ili VM-bazirane modele rada; često stabilni u dugotrajnom radu, dobra automatizacija preko systemd.
• Microsoft IIS: uspostavljeno hostiranje za web-aplikacije i reverse-proxy scenarije u Windows-centriranim okruženjima.

Važno je da Delphi- i C#-komponente zadovoljavaju slične operativne standarde: konzistentni Health-Endpoints (Lebenszeichen), definirani Timeouts, ograničena potrošnja resursa, kao i jasan Deployment- i Rollback-postupak. To smanjuje „technologiespezifische“ posebne tretmane.

Logging, Tracing und Metriken: ein gemeinsames Observability-Niveau

Posebno kod dva tehnološka stacka kontinuirani dijagnostički lanci su presudni. Tipičan problem: Delphi-klijent prijavljuje „Fehler beim Speichern“, C#-servis ima timeout, baza podataka prijavljuje zaključavanja – bez zajedničkog konteksta.

U praksi su se pokazali sljedeći pristupi:

• Korrelacijske ID-ove po zahtjevu (Client → API → DB), kako bi se logovi mogli povezati.
• Strukturirano logiranje (ključ/vrijednost umjesto čistih tekstualnih linija), radi kasnijeg filtriranja.
• Metrike za latenciju, stope pogrešaka, duljine redova i upotrebu resursa.
• Klasifikacija grešaka: poslovne greške (validacija) odvojeno od tehničkih grešaka (timeout, mreža).

Ove osnove u praksi štede više vremena nego svaka rasprava o „ispravnom jeziku“.

Pristup podacima i migracija: BDE-zamjena, FireDAC i moderne baze podataka

U Delphi okruženjima pristup podacima povijesno ima veliku ulogu. Ako su još u upotrebi stari pristupni putevi poput Borland Database Engine (BDE), pojavljuje se dodatni pritisak: ažuriranja operativnog sustava, prelazak na 64‑bit, dostupnost drajvera, sigurnosni zahtjevi. BDE-zamjena tada nije samo modernizacija, već smanjenje rizika.

Tipično je prebacivanje na BDE-zamjena s nativnim povezivanjem (moderni sloj za pristup podacima u Delphi), u kombinaciji s bazom podataka koja je operativno dobro upravljiva (npr. PostgreSQL, SQL Server, MariaDB). Za zajedničku Delphi/C#-arhitekturu važna su dva aspekta:

• Granice transakcija: Tko pokreće/commitira transakcije i kako se reguliraju paralelni zapisni pristupi?
• Strategija zaključavanja i izolacije: tako da se radni tokovi na desktopu i servisi ne blokiraju međusobno.

Kod migracija se isplati fazno planiranje: prvo modernizirati drajvere i sloj pristupa, zatim konsolidirati model podataka, potom stabilizirati integracijska sučelja. Tako se izvori pogrešaka mogu izolirati, a povratne operacije (Rollbacks) postaju realistične.

Release-Management: uskladiti različite cikluse ažuriranja

Ponavljajuće područje napetosti je učestalost ažuriranja: web-servisi se mogu češće uvoditi, desktop-klijenti često rjeđe (rollout-prozori, komunikacija s korisnicima, paketiranje). Zajednička arhitektura mora uzeti u obzir ovu asimetriju.

Praktične posljedice:

• Unazadna kompatibilnost API-ja je obavezna, ne opcionalna.
• Feature Flags (funkcionalni prekidači) pomažu kontrolirano aktivirati nove funkcije na serverskoj strani.
• Migracije sheme moraju se provoditi fazno: najprije proširiti bazu podataka, zatim servis počne koristiti nove strukture, pa potom ažurirati klijenta.
• Jasna deprecacija: stare endpoint-e ili polja ukloniti tek nakon definiranog razdoblja.

Posebno u reguliranim okruženjima važno je ova pravila pisanim oblikom fiksirati kao arhitektonske smjernice, kako se odluke ne bi iznova izmišljale po projektu.

Tipične zamke i kako ih sustavno izbjeći

Iz operativne perspektive, najčešći problemi u mješovitim Delphi/C# okruženjima su dobro predvidljivi. Ako ih se rano adresira, dugoročni troškovi znatno se smanjuju.

Zamka 1: dvostruka poslovna logika

Ako Delphi-klijent i C#-servis iste poslovne règle implementiraju različito, nastaju „nevidljive greške“: proces radi u UI-ju, ali zakaže pri API-importu. Protivmjera: centralizirati pravila u sloju domene (servis) ili ih jasno domenski dodijeliti, uključujući jednoznačne odgovore pri validaciji.

Zamka 2: UI-zaobilaznice umjesto čistih sučelja

„Brzo upisati polje u bazu“ u pojedinačnom slučaju djeluje bezazleno, ali stvara skrivene sučelje bez logiranja, autentikacije i verzioniranja. Bolje: dosljedno koristiti definirane endpoint-e, iako to u početku zahtijeva veću disciplinu.

Zamka 3: nejasne odgovornosti u operativnom radu

Ako nije jasno koji tim je odgovoran za koji servis, koji log i koje operativne parametre, ispitivanje pogrešaka završi u ping-pongu. Praktično pomaže karta servisa (koji servis, koje ovisnosti, koji portovi, koje interne SLA-e) i jedinstveni runbookovi za česte smetnje.

Poteškoća 4: nedostatak sigurnosne dosljednosti

Portal sa SSO-om, ali desktop-klijent s lokalnim administratorskim računima predstavlja problem u mnogim auditima. Zajednički model identiteta i uloga smanjuje rizik i opterećenje podrške.

Pomoć pri odluci: Što ostaje u Delphi, što prelazi u C#?

Smislena podjela ovisi manje o ideologiji, a više o blizini procesu i operativnim zahtjevima. Kao orijentacija iz arhitektonske i operativne perspektive:

• Delphi često je dobar za: postojeće Windows-desktop-klijente (VCL), vrlo reaktivne UI-workflowe, scenarije bliske offline radu, dugoročno održavanje naslijeđenih sučelja.
• C# često je dobar za: centralne REST-API-je, integracijske servise prema ERP/DMS/CRM, komponente bliske identitetu, portale i backend-procese s visokom učestalošću promjena.
• Svjesna odluka: logika podataka i validacija ne bi trebale biti „u klijentu“ ako postoji više frontenda (desktop, portal, import-jobovi).

Važno: cilj nije „sve u C#“, nego robusna cjelovita arhitektura u kojoj su koraci modernizacije planirani i poslovni procesi rade stabilno.

Put modernizacije: postupno od aplikacije prema sustavu

U praksi je zajednička arhitektura često prijelaz, ali dugotrajan. Realističan put modernizacije izbjegava velike projekte visokog rizika i oslanja se na mjerljive međuciljeve:

1. Stabilizirati sučelja: uvesti REST-API kao funkcionalnu granicu, čak i ako interno nije sve „lijepo“.
2. Modernizirati pristup podacima: BDE-Ablösung, driveri, podrška za 64‑bit, jasne transakcije.
3. Centralizirati identitet: SSO i model uloga za sve načine pristupa.
4. Ujednačiti operacije: Logging/Monitoring/Health, jasni deploymenti, reproducibilna okruženja.
5. Odvojiti funkcionalne module: posebno dijelove intenzivne za promjene premjestiti u servise, postupno smanjivati složenost UI-ja.

Ovaj redoslijed nije dogmatski, ali tipično minimizira ovisnosti: bez stabilnih sučelja i operativnog koncepta svaka daljnja promjena bit će skuplja.

Zaključak: integracija je arhitektonsko pitanje, ne pitanje jezika

Nosiva kombinacija Delphi i C# ne nastaje kroz „Brückenbibliotheken“, nego kroz jasne funkcionalne granice, čiste ugovore o podacima i operativni koncept koji ozbiljno shvaća monitoring, sigurnost i upravljanje izdanjima. Kada C# i Delphi u zajedničkoj arhitekturi svjesno surađuju duž odgovornosti, tvrtke dobivaju prije svega jedno: modernizaciju bez prekida procesa. Delphi može i dalje pouzdano podržavati stabilne desktop-workflowe, dok C#-servisi pružaju integraciju, web-API-je i portale kao centralne platformne funkcije.

Ako želite postojeću Delphi-landskapu postupno modernizirati ili uredno povezati C#-servise, arhitekturni review s fokusom na sučelja, podatke, operacije i sigurnost najbrži je put do pouzdanih odluka. Više o tome u izravnom razgovoru:

U stručnom kontekstu važnu ulogu imaju i Delphi modernizacija te REST-API za postojeći softver, kada integracije, tokovi podataka i daljnji razvoj moraju usklađeno djelovati.

Razgovarajte o projektu ili planu modernizacije s Net-Base.