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

U mnogim IT-odjelima polazna situacija je slična: stabilna, procesno-bliska Delphi-desktop aplikacija podržava kritične tokove, dok nove zahtjeve guraju prema webu, portalima, mobilnoj upotrebi i integraciji s cloud uslugama. Istovremeno je C# u mnogim poduzećima postao standard kada je riječ o servisima, web-API-jima i integraciji identiteta. Stoga središnje pitanje više nije „Delphi oder C#?“, nego: C# und Delphi in einer gemeinsamen Architektur kombinirati tako da upravljanje, održavanje, pohrana podataka i sigurnost ostanu pod kontrolom.

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

Zašto su mješoviti stackovi u poduzećima uobičajeni

Rastuća digitalna poslovna rješenja rijetko nastaju na zelenom polju. Delphi-aplikacije često su se godinama nadograđivale, blisko poslovnim procesima, s opsežnom podatkovnom logikom i dubokim znanjem o iznimkama. Paralelno su se pojavljivali novi zahtjevi: self-service portali, automatizirane razmjene podataka, povezivanje DMS/CRM/ERP sustava, podrška za više klijenata (multitenancy), veća auditabilnost ili Single Sign-on.

C# u tom kontekstu često donosi 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 pak jak kada su u pitanju performantni Windows desktop-klijenti, dugoročno održavane VCL-aplikacije ili specifični multiplatform-klijenti (npr. putem FMX).

Zbog toga ta mješavina nije „poseban slučaj“, već realan odgovor na zaštitu investicija i pritisak za modernizacijom. Presudno je da zajedničko upravljanje ne postane stalno gradilište.

Arhitektonski princip: jasni slojevi umjesto razgraničenja po jeziku

Kada se sretnu dvije tehnologije/jezika, velika je napast organizirati razdvajanje duž tehnoloških linija („Sve što je Delphi je Legacy, sve što je C# je novo“). Tehnički to često funkcionira kratkoročno, ali dugoročno vodi do trenja: dupliciranih poslovnih pravila, nejasnih odgovornosti i teško reproducibilnih pogrešaka.

Umjesto toga pokazala se učinkovita stručna slojevitost, često ostvarena 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 svakodnevnoj učinkovitosti: odluke o podacima, validacijama i workflowima donose se na jednom mjestu i izlažu preko stabilnih sučelja.

U mješovitoj arhitekturi to praktično znači: Delphi može i dalje isporučivati UI-dio (ili određene workflowe), dok C# Services mogu kapsulirati stručni domenski sloj – ili obrnuto. Važno je da rub između slojeva bude tehnički čist i testabilan.

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

Za povezivanje Delphi i C# ne postoji „jedan“ ispravan način. Dobre odluke usmjeravaju se na rad sustava, sigurnosne zahtjeve, latenciju, volumen podataka i cikluse izdanja. U praksi su se istaknula tri obrasca.

1) Servisna Orijentacija über HTTP/REST als Standardkopplung

Najrobustnija za rad i daljnji razvoj često je povezanost preko REST-APIs (HTTP-bazirane sučelja). Delphi-klijenti pozivaju C#- ili Delphi-servise; C#-portali koriste iste krajnje točke. Ovo odvajanje čini izdanja planiranijima: ažuriranje klijenta nije nužno ako API ostane unatrag kompatibilan.

Važna je profesionalna izvedba: timeoti (timeouts), ponovni pokušaji (retries), idempotencija (ponovljivi zahtjevi bez nuspojava), jasni kodovi pogrešaka i strategija verzioniranja. Za administraciju i operacije računaju i dosljedni logovi, jasno pratljive ID-ove zahtjeva i dobro mjerivo vrijeme odgovora.

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

Zajednički pristup bazi podataka izgleda primamljivo jer je isprva brz. Dugoročno je međutim rizičan ako oba svijeta izravno pišu u isti skup tablica. Razlog: poslovna pravila preseljavaju se u trigger-e, pohranjene 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:

• Centralizirati zapisne pristupe: jedan sustav je „System of Record“ za određene entitete.
• Definirati ugovore: View-i ili API-ji kao stabilan sloj za čitanje umjesto izravnog pristupa tablicama.
• Planirati migracijska razdoblja: promjene u bazi podataka uvijek uvoditi unatrag kompatibilno (npr. nove kolone prvo označiti kao opcionalne).

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

3) Messaging/Events za asinkrone procese

Za odvojene tokove (npr. importni poslovi, obavijesti, naknadna obrada, poslovi sučelja) smislen je asinkroni model: jedan sustav publikuje događaje, drugi ih obrađuje. To smanjuje izravne ovisnosti i stabilizira vrhove opterećenja.

Za IT-upravljanje i administratore ovdje je važno: monitoring (duljine redova), dead-letter koncepti (neuspjele poruke), ponašanje pri ponovnom pokretanju i jasna funkcionalna idempotencija. Events nisu zamjena za uredno vođenje osnovnih podataka, ali su koristan alat za robusne procesne lance.

Ugovori o podacima i kompatibilnost: potcijenjena srž

Neovisno o obrascu integracije, o stabilnosti odlučuje kvaliteta ugovora o podacima. 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.

Dokazane smjernice koje znatno pojednostavljuju rad:

• Proširivati umjesto prekidati: dodavati nova polja, stare polja najprije i dalje isporučivati.
• Dokumentirati semantiku polja: ne samo „string“, nego npr. ISO-datum, vremenska zona, dozvoljena stanja.
• Tretirati enum-vrijednosti tolerantno: klijenti moraju tolerirati nepoznate vrijednosti (kompatibilnost unaprijed).
• Svjesno koristiti verzioniranje API-ja: ne svako izdanje zahtijeva novu verziju; ali promjene koje narušavaju kompatibilnost moraju biti jasno kapsulirane.

Ove točke su posebno važne kada se Delphi-desktop-klijenti ne mogu ažurirati toliko često kao web-servisi.

Autentifikacija i autorizacija: zajednički sigurnosni model

Miješane arhitekture rijetko ne uspijevaju zbog „Technik“, češće zbog nekonzistentne sigurnosti. Za poduzeća je presudno: Tko smije što? Kako se to provjerava? Kako se to revizira? Jedan zajednički model izbjegava dvostruku upravu korisnicima i kontradiktorne uloge.

U praksi to vodi ka centralnom sloju identiteta: npr. preko SAML 2.0 (federirano Single Sign-on, često u Enterprise-Umfeld) ili OpenID Connect (temeljen na OAuth2, često za moderne web‑API‑je). C#-Services obično se mogu izravno povezati na Identity Provider; Delphi-klijenti mogu dohvatiti tokene i slati ih pri API‑pozivima. Važno je da ni desktop‑aplikacije ne dobivaju „Sonderrechte“ putem izravnog pristupa bazi podataka.

Za administratore ključno:

• Trajanje tokena i strategija osvježavanja (da klijenti rade stabilno, a ipak ostanu sigurni)
• Autentifikacija servis‑prema‑servis za internu komunikaciju (npr. mTLS ili potpisani tokeni)
• Princip najmanjih privilegija: uloge i dozvole ne dodjeljivati preširoko
• Audit-Logs: sigurnosno relevantne radnje evidentirati tako da se mogu rekonstruirati

Betriebskonzepte: Windows- und Linux-Services, IIS und Prozesse im Alltag

Arhitektura je u poduzeću dobra samo ako je održiva u radu: ažuriranja planirana, pogreške lokalizirane, opterećenje pod kontrolom. U miješanim krajolicima najčešći operativni modeli su:

• Windows- und Linux-Services: pogodni za pozadinske zadatke, pokretanja sučelja, workere; dobro se integriraju u klasične Windows-serverske modele rada.
• Windows- und Linux-Services/Daemon: razumno za kontejnerizirane ili VM‑bazirane modele operacija; često stabilni u dugotrajnom radu, dobra automatizacija preko systemd.
• Microsoft IIS: etablirano hosting rješenje 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: konzistentne Health‑Endpoints (Lebenszeichen), definirani time‑outovi, ograničena potrošnja resursa, te jasno definirani postupci za deployment i rollback. To smanjuje „technologiespezifische“ posebne tretmane.

Logging, Tracing und Metriken: ein gemeinsames Observability-Niveau

Posebno kod dva tehnološka stacka kontinuirane dijagnostičke lance su presudne. Tipičan problem: Delphi‑klijent prijavljuje „Fehler beim Speichern“, C#‑service ima timeout, baza podataka prijavljuje zaključavanja – bez zajedničkog konteksta.

U praksi se pokazalo učinkovitim:

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

Ove osnove u praksi štede više vremena nego bilo koja rasprava o „pravom jeziku“.

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

U Delphi-sustavima pristup podacima povijesno ima veliku ulogu. Gdje su još u upotrebi stari putevi pristupa kao Borland Database Engine (BDE), javlja se dodatni pritisak: ažuriranja operativnog sustava, prelazak na 64‑bitne sustave, dostupnost upravljačkih programa, sigurnosni zahtjevi. BDE-zamjena tada nije samo modernizacija, već i smanjenje rizika.

Tipično je prelazak na BDE-zamjenu s izvornom vezom (moderan sloj pristupa podacima u Delphi), kombinirano s bazom podataka koja je u operativnom radu jednostavna za rukovanje (npr. PostgreSQL, SQL Server, MariaDB). Za zajedničku Delphi/C# arhitekturu važna su dva aspekta:

• Granice transakcija: Tko pokreće/potvrđuje transakcije i kako se reguliraju paralelni zapisi?
• Strategija zaključavanja i izolacije: kako bi se radni tokovi na desktopu i servisi međusobno ne blokirali.

Kod migracija se pokazuje korisnom fazna planiranja: prvo modernizirati upravljačke programe i sloj pristupa, zatim konsolidirati podatkovni model, a potom stabilizirati integracijska sučelja. Tako se izvori pogrešaka mogu izolirati i poništavanje postaje realističnije.

Upravljanje izdanjima: usklađivanje različitih ciklusa ažuriranja

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

Praktične posljedice:

• Unatrag kompatibilnost API-ja je obavezna, ne opcionalna.
• Feature Flags (funkcionalni prekidači) pomažu kontrolirano aktivirati nove funkcije na strani servera.
• Migracije sheme moraju se provoditi u fazama: prvo proširiti bazu podataka, zatim koristiti servis, pa potom ažurirati klijenta.
• Jasna deprecacija: stare krajnje točke ili polja ukloniti tek nakon definiranog razdoblja.

Pogotovo u reguliranim okruženjima važno je ta pravila pisano fiksirati kao arhitekturne smjernice, kako se odluke ne bi iznova pronalazile za svaki projekt.

Tipične zamke i kako ih sistematski izbjeći

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

Zamka 1: dvostruka poslovna logika

Ako Delphi-klijent i C#-servis implementiraju iste pravila različito, nastaju „duhovi pogrešaka“: proces radi u UI-u, ali ne uspijeva pri uvozu putem API-ja. Protivmjera: centralizirati pravila u domenskom sloju (servis) ili ih jasno dodijeliti po domeni, uključujući jednoznačne odgovore za validaciju.

Zamka 2: UI-zaobilazna rješenja umjesto čistih sučelja

„Brzo upisati još jedno polje u bazu“ u pojedinačnom slučaju djeluje bezazleno, ali stvara sjenovita sučelja bez logiranja, autentikacije i verzioniranja. Bolje: dosljedno koristiti definirane krajnje točke, iako to u početku zahtijeva više discipline.

Zamka 3: nejasne odgovornosti u operacijama

Ako nije jasno koji tim je odgovoran za koju uslugu, koji log i koje operativne parametre, traženje grešaka završava kao ping-pong. Praktično pomaže karta servisa (koja usluga, koje ovisnosti, koji portovi, koje interne SLA) i ujednačeni runbookovi za česte kvarove.

Zamka 4: nedostatak sigurnosne dosljednosti

Portal sa SSO-om, a 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 odlučivanju: Što ostaje u Delphi, a što ide u C#?

Razumnu podjelu manje određuje ideologija, a više blizina procesima i operativni zahtjevi. Kao orijentacija iz arhitektonskog i operativnog pogleda:

• Delphi često je dobar za: postojeće Windows-desktop-klijente (VCL), vrlo responzivne UI tokove rada, scenarije bliske offline radu, dugoročno održavanje razvijenih korisničkih 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 frekvencijom promjena.
• Svjesno odlučite: logika podataka i validacija ne bi smjele biti „u klijentu“ ako postoji više frontenda (desktop, portal, poslovi uvoza).

Važno: Cilj nije „sve u C#“, već robusna ukupna arhitektura u kojoj su koraci modernizacije planirani i poslovni procesi stabilno funkcioniraju.

Put modernizacije: postepeno od aplikacije prema sustavu

U praksi je zajednička arhitektura često prijelaz, ali dug. 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 još nije sve „uređeno“.
2. Modernizirati pristup podacima: BDE-zamjena, drajveri, 64‑Bit-podrška, 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 s visokom stopom promjena premjestiti u servise, UI postupno pojednostaviti.

Ovaj redoslijed nije dogmatski, ali tipično minimizira ovisnosti: bez stabilnih sučelja i koncepta operacija svaka daljnja promjena postaje skuplja.

Zaključak: Integracija je arhitektonski zadatak, a ne pitanje programskog jezika

Održiv spoj Delphi i C# ne nastaje kroz „mostovne biblioteke“, nego kroz jasne funkcionalne granice, čiste ugovore o podacima i koncept operacija koji ozbiljno shvaća monitoring, sigurnost i release-management. Kada C# i Delphi u zajedničkoj arhitekturi svjesno djeluju 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 postupno modernizirati postojeće Delphi-okruženje ili čisto povezati C#-servise, arhitektonski pregled s fokusom na sučelja, podatke, operacije i sigurnost najbrži je put do pouzdanih odluka. Više o tome u izravnoj razmjeni:

U stručnom okruženju također važnu ulogu imaju Delphi modernizacija i REST-API za postojeći softver, kada integracije, tokovi podataka i daljnji razvoj moraju besprijekorno surađivati.

Razgovarajte o projektu ili planu modernizacije s Net-Base.