Delphi Desktop ve Web portallarını birleştirmek: Mimari, arabirimler ve kesinti olmadan modernizasyon

Birçok şirkette mesleki „kumanda merkezi“ yıllar içinde bir Delphi-masaüstü uygulaması olarak büyümüştür: VCL-istemci, derin süreç bilgisi, hızlı veri yakalama, yazdırma ve raporlama hatları, özel donanım ve sıkça LAN içinde doğrudan veritabanı erişimi. Aynı zamanda self-service ve dış işbirliği beklentileri artıyor: Müşteriler sipariş durumlarını kontrol etmek, belgeleri paylaşmak veya şikayet kaydı oluşturmak istiyor — VPN olmadan, masaüstü dağıtımı olmadan ve yerel kurulum olmadan.

Delphi Desktop und Web-Portale kombinieren uygulamada bu iki dünyayı işletme, güvenlik ve veri tutarlılığı yönetilebilir kalacak şekilde birleştirmek anlamına gelir. Önemli olan maskeleri tarayıcıda „kopyalamak“ değil; süreçleri, hakları ve veri yollarını net şekilde ayıran ve her iki ön yüzün ortak kurallar üzerinden çalışmasını sağlayan bir mimaridir. Kazanç, Big-Bang olmadan ilerleyen bir modernizasyon yoludur: Masaüstü üretken kalırken web portalı kontrollü şekilde büyür.

Bu yazı IT yöneticilerine, sistem yöneticilerine ve teknik proje sorumlularına yöneliktir. Odak noktası işletme, yönetim, arayüzler, güvenlik, veri saklama ve göç üzerindeki etkilerdir — framework detaylarından ziyade. Size pratik örüntüler, karar kriterleri ve tipik tuzaklar ile birlikte karşı önlemler sunulacak.

Neden „Portal yerine Desktop“ nadiren gerçekçidir

B2B ortamlarında bir masaüstü istemcisinin halen mantıklı olmasının birçok nedeni vardır. Yöneticiler bunu sıklıkla somut şekilde yaşarlar: Bir portal dağıtık kullanıcılar için idealken bazı görevler masaüstünde daha verimli veya ancak masaüstünde mümkündür.

Masaüstünün günlük hayatta öne çıkan güçlü yönleri

• Karmaşık veri yakalama: çok yoğun formlar, klavye odaklı kullanım, büyük tablo görünümleri ve kayıtlar arasında hızlı geçişler.
• Çevre birimleri ve yerel entegrasyonlar: etiket yazıcıları, barkod okuyucular, seri cihazlar veya özel Windows bileşenleri gibi donanımlar.
• LAN-ye yakın performans: büyük veri hacimleri işlendiğinde veya bir süreç çok düşük gecikme gerektirdiğinde.
• Büyümüş iş akışları: birçok istisna içeren, 1:1 bir porteledene geçişin başlangıçta yüksek risk taşıyacağı olgunlaşmış süreçler.

Portalın yeni gereksinimleri karşılayan güçlü yönleri

• Dış erişim: müşteri, tedarikçi veya partnerler için istemci dağıtımı gerektirmeyen erişim.
• Merkezi kontrol (sürümler, özellikler, izinler) ve net bir dış kenar.
• Cihaz bağımsızlığı (tarayıcı, mobil kullanım) saha ekibi ve yönetim için.
• Hedefli süreç açıklıkları: durum sorgulamaları, yüklemeler, onaylar veya ticket akışları gibi sınırlı süreç açılımları.

Birlikte kullanıldıklarında fayda ortaya çıkar: Masaüstü dahili roller için güçlü bir araç olarak kalır, portal ise harici kullanıcı grupları için kontrollü erişim sağlar. Bunun iki paralel „gerçeklik“e dönüşmemesi için bağlayıcı bir çekirdeğe ihtiyaç vardır.

Delphi Desktop und Web-Portale kombinieren: üç hedef mimari

Mimari kararı esas olarak sorumluluklarla ilgilidir: Mesleki kural nerede tanımlanır? Kim veriyi değiştirebilir? Hangi katman „Single Source of Truth“ (yani kurallar ve durumlar için belirleyici kaynak) olur? Teknik karar vericiler için önemli olan: seçim işletme, hata bulma, sürüm yönetimi ve güvenlik üzerinde doğrudan etkilere sahiptir.

Varyant A: Portal REST-API üzerinden tamamlayıcı, masaüstü lider kalır

Portal tipik olarak „okuma ve tetikleme“ gibi seçilmiş kullanım senaryolarını sunar: durum, belgeler, onaylar, basit kayıtlar. Bunun için bir Delphi REST-API veya ayrı bir REST-Server devreye alınır. Masaüstü uygulama başlangıçta doğrudan veritabanına erişmeye devam edebilir.

Operasyonel avantaj: hızlı başlangıç, masaüstünde az müdahale, ilk portal değer katmanı için uygun.

Risk noktası: İki veri yolu vardır (Masaüstü → DB doğrudan, Portal → API). İş kuralları sadece masaüstünde kaldığında tutarsızlıklar doğar. Karşı önlem olarak portal fonksiyonları sunucuda kolayca temsil edilebilen kurallarla sınırlı başlatılmalıdır (ör. belge sağlama, durum sorgulama, tanımlı onay eylemleri).

Varyant B: Ortak süreç katmanı olarak servis çekirdeği (paralel işletme için önerilir)

Burada iş mantığını kademeli olarak masaüstünden servislere taşırsınız. Masaüstü ve portal aynı uç noktaları kullanır. Masaüstü daha çok zengin istemci (UI, yerel entegrasyonlar) olurken kurallar ve doğrulamalar sunucu tarafında yer alır.

Operasyonel avantaj: haklar, audit, durum mantığı ve doğrulamalar için merkezi bir nokta; tüm ön yüzlerde tutarlı davranış.

Çaba: başta daha yüksektir, çünkü API standartları, hata formatları, versiyonlama, monitoring ve dağıtım net planlanmalıdır. Karşılığında ileride çaba önemli ölçüde düşer, çünkü istisnai yollar azalır.

Varyant C: Portal lider, masaüstü özel istemci olarak kalır

Bu varyant, tarayıcının stratejik olarak standart erişim olacağı durumlarda (ör. güçlü dağıtık organizasyon) mantıklıdır; ancak masaüstü belirli rollerde özel donanım veya yüksek performans yakalama amacıyla kalır. Bu senaryoda servis çekirdeğinin özellikle stabil ve ölçeklenebilir olması gerekir.

Layer-3 Architektur als verständliche Leitlinie

Varyantlardan bağımsız olarak bir Layer-3 Architektur yardımcı olur: (1) Sunum (Masaüstü/Portal), (2) Uygulama ve domain katmanı (kullanım senaryoları, kurallar), (3) Altyapı (veritabanı, dosya depolama, messaging, dış sistemler). Yöneticiler için bu önemlidir çünkü işletme sınırları netleşir: „Frontend problemi“ ne, „Servis problemi“ ne, veritabanı veya storage içinde ne yer alır? Bu ayrım hata bulmayı kısaltır ve deploy’larda yan etkileri azaltır.

Pratik uygulama: Masaüstü ve Portal aynı süreci nasıl paylaşır

En büyük zorluk genellikle „portalı inşa etmek“ değil, masaüstü ve portalın aynı süreçte sorumlulukları nasıl paylaştığıdır, böylece kurallar çift uygulanmaz. Pratikte üç örüntü özellikle önemlidir.

1) Tablolar- veya CRUD-API’leri yerine Use-Case-API’leri

Sık karşılaşılan tıkanma, sadece veritabanı tablolarını dışa açan bir API’dir („Create/Read/Update/Delete“). Bu durumda kurallar portalda yeniden oluşturulmak zorunda kalır ve masaüstü kendi kurallarıyla kalır. Daha iyi olan Use-Case-API’leridir: uç noktalar „şikayet oluştur“, „siparişi onayla“, „belge yükle“, „teslimat durumunu onayla“ gibi mesleki eylemleri tanımlar.

İşletmedeki etkisi nettir: doğrulamalar sunucu tarafında gerçekleşir, hata bildirimleri tekrarlanabilir olur ve her iki istemci de aynı mantık üzerinden aynı akışı tetikler.

2) Çakışmalar ve tekrarları yönetilebilir kılmak

Bir portal ile paralel değişiklikler ve tekrarlayan istekler (ör. timeout’lar, retry’ler veya kullanıcı çift tıklamaları) daha olası hale gelir. Burada „kalişıcı kilitler“ getirmeden yardımcı olan üç kavram vardır:

• İdempotenz: Kritik eylemler, tekrarlandıklarında aynı etkiyi üretir ve çift işlem yapılmaz. Pratikte bu genellikle benzersiz bir istek kimliği (Idempotency Key) ile sağlanır.
• Optimistic Concurrency: Bir kayıt bir sürüm bilgisini taşır (ör. „Row Version“). Değişikliklerde servis, sürümün halen geçerli olup olmadığını kontrol eder ve çakışmaları temiz şekilde geri döner.
• Kısa işlemler: „Her şeyi kilitle“ yerine yazma işlemleri kısa tutulur. Uzun süren işler (ör. dışa aktarımlar, rapor paketleri) asenkron olarak yürütülür.

Teknik karar vericiler için önemli olan: Bu mekanizmalar destek iş yükünü azaltır, çünkü „iki kez oldu“ veya „değişiklik kayboldu“ gibi hata görüntüleri daha az görülür.

3) Durumlar ve geçişleri net modellemek

Masaüstü karmaşık vakaları işlerken ve portal „sadece“ talepler veya ön aşamalar gönderiyorsa, tanımlı durum geçişlerine ihtiyacınız olur. Pratik bir yaklaşım: Portal belirli sınırlı durum aralıklarında işlem oluşturur veya tamamlar (ör. „gönderildi“), masaüstü özel vakaları işler, servis çekirdeği durum değişikliklerini değerlendirir ve kaydeder. Böylece portal istemcisinin dolaylı olarak süreçleri „yanlış yapılandırmasının“ önüne geçilir.

Veriler ve belgeler: sık hafife alınan entegrasyon alanı

Hemen her portal dosya işlemleri getirir: yüklemeler, kanıtlar, teslimat belgeleri, resimler, PDF çıktıları. Yöneticiler için bu bir odak noktasıdır çünkü yedekleme, izinler, virüs taraması, storage maliyetleri ve performansı etkiler.

Dosyalar nerede saklanmalı: Veritabanı, Fileshare veya Obje-Depolama?

Her biri farklı işletme gerçekliği getiren üç yaygın depolama seçeneği vardır:

• Veritabanı (BLOB): işlemlerin sıkı şekilde bağlanması gerektiğinde ve backup/restore her şeyi tek paket halinde tutmalıysa uygundur. Dezavantajları genellikle daha büyük veritabanları ve uzayan yedekleme pencereleridir.
• Filesystem/Share: tipik olarak on-prem, mevcut yedekleme konseptlerine iyi entegre olur. Önemli olan net izinler ve erişimi kontrol eden bir API katmanıdır.
• Objekt-Storage: ölçeklendirme, yaşam döngüsü kuralları veya dış erişimlerin teknik olarak temiz izole edilmesi gerektiğinde mantıklıdır. Bu, anahtar ve izin modelinin bilinçli tasarımını gerektirir.

Depolama yerinden bağımsız olarak geçerli olan: Portal dosyaları bir share’den „doğrudan“ indirmemelidir. Daha iyi olan, izin kontrolü, protokollendirme ve opsiyonel süreli indirme URL’si ile servis uç noktaları üzerinden kontrollü indirmedir.

PDF’ler ve raporlar: sunucu tarafı, çift uygulama yerine

Delphi-masaüstü uygulamaları sıklıkla gelişmiş yazdırma ve raporlama hatlarına sahiptir. Portaller de aynı içerikleri PDF olarak ister. İki ayrı uygulamayı sürdürmek yerine merkezi belge üretimi servis çekirdeğinde anlamlıdır: şablonlar, versiyonlama ve çıktı formatı sunucu tarafında yer alır; masaüstü ve portal sonucu tüketir. İşletme açısından bunun avantajları açıktır: izlenebilir çıktılar, tek tip saklama ve masaüstü kurulumlarına daha az bağımlılık.

REST-Server ve servisler: Delphi, C# veya karışık mimari

„Delphi mu yoksa C# mu“ kararı şirketler için ideolojiden çok ekip yetkinliği, işletme ortamı ve sürdürülebilirlikle ilgilidir. Birçok ortamda, sorumluluklar net kesildiği sürece karma mimari gerçekçidir.

Var olan iş mantığı varsa Delphi servis platformu mantıklıdır

İş mantığı ve veri erişimi zaten Delphi içinde sağlamsa, bir Delphi tabanlı REST-Server verimli olabilir. Yöneticiler ve karar vericiler için önemli olan: sunucu işletimi „masaüstüğün sürekli çalışması“ değildir. Prodüksiyon servisi net konfigürasyonlar, uygun timeout’lar, yapılandırılmış loglar, health-check’ler ve tekrarlanabilir deployment gerektirir.

Ayrıca veri bağlantısının modernize edilmesi gerekir, eğer eski sürücüler veya BDE hâlâ kullanımdaysa. Bir BDE-Ablösung ve modern veri erişimlerine geçiş işletmedeki aksaklıkları azaltır ve deployment’ı kolaylaştırır, çünkü daha az legacy bileşen kurulup yönetilmesi gerekir.

C# servisleri portal ekosisteminde: sıklıkla hosting ve identity nedenleriyle

Portal .NET ağırlıklı bir landschaft içinde inşa ediliyorsa, C# Services sıklıkla mantıklıdır — özellikle Identity entegrasyonu, mevcut işletim standartları ve Microsoft IIS veya container platformları arkasında barındırma nedeniyle. Önemli olan çift uygulamayı önlemektir: Ya mesleki çekirdek mantık Delphi servislerinde kalır ve C# edge konularını (ör. portal-spesifik orkestrasyon) üstlenir, ya da mantığın .NET’e kontrollü ve net sınırlarla göçü planlanır.

API-Gateway: düzen unsuru ama zorunlu değil

Bir API-Gateway merkezi fonksiyonları birleştirebilir (routing, rate-limits, logging, authentication). Daha küçük başlangıç mimarileri için genellikle tutarlı standartlara sahip bir API yeterlidir. Ancak birden fazla servis ve kullanıcı grubu ortaya çıktığında, gateway dış kenarı stabil tutmaya ve politikaları merkezi uygulamaya yardımcı olur.

Kimlik doğrulama ve yetkilendirme: dahili masaüstüden dış portala

Portal ile kullanıcı profili değişir: dahili kullanıcıların yanında harici hesaplar, roller ve tenant’lar eklenir. Bundan identity, izinler ve denetlenebilirlik gereksinimleri doğar. Yöneticiler için bunun önemi, identity sistemleri ve rol modellerinin sonradan değiştirilmesinin zor olmasıdır.

SAML 2.0 veya OIDC ile SSO: daha az yönetim, daha iyi kontrol

B2B kurulumlarda SAML 2.0 (Identity Provider üzerinden Single Sign-on) yaygındır; çünkü şirketler mevcut kimlikleri kullanmak ister. OIDC (OpenID Connect) de özellikle daha modern platformlarda sık kullanılır. Klasik kullanıcı/şifre oturumları mümkün olsa da, parola politikası, MFA, reset süreçleri ve destek maliyetleri ek yük getirir.

Mimari için önemli: kimlik doğrulama (sen kimsin?) ve yetkilendirme (ne yapabilirsin?) sunucu tarafında doğrulanmalıdır — portal frontend’de değil.

Çoklu müşteri (multitenancy) ve rol modeli: „sonradan“ eklenmemeli

Bir müşteri portalı pratikte her zaman tenant ayrımı gerektirir: Bir müşteri yalnızca kendi verilerini görmelidir. Bu servis çekirdeğinde şu şekilde uygulanmalıdır:

• Token içindeki claim’ler (ör. Tenant-ID, roller, sözleşme referansı), böylece servisler karar verebilir.
• Kayıt bazlı kontroller (Row-Level-Checks) yalnızca „menüyü gizlemek“ ile sınırlı olmamalıdır.
• Audit-Trail’ler önemli eylemler için (kim, ne, ne zaman) ve hata analizine yönelik bir Request-ID ile korelasyon.

Masaüstü istenirse aynı Identity-stack’e karşı token kullanabilir. Bu, istisnai yolları azaltır ve özellikle portal ile masaüstü aynı kaydı düzenlediğinde değişikliklerin izlenmesini kolaylaştırır.

Veri erişimini modernize etmek: FireDAC, PostgreSQL ve kontrollü veri yolları

Birçok Delphi-masaüstü çözümü tarihsel olarak doğrudan DB erişimi ile büyümüştür. Bir portal eklendiğinde bu mimari bir konu haline gelir: Veri yolları kontrol edilebilir olmalı, doğrulamalar merkezi çalışmalı ve paralel yük altında performans stabil kalmalıdır.

FireDAC bakım yapılabilir veri erişimi için temel

BDE-Ablösung mit nativer Anbindung Delphi ortamlarında modern veritabanlarına erişim için yaygın bir standarttır. Önemli olan bileşenin kendisinden çok birleştirmedir: parametreli sorgular, net işlem sınırları, tutarlı hata işleme ve ölçülebilir çalışma süreleri. İşletme açısından önemli olan, timeout’ların ve kaynak tüketiminin planlanabilir olması ve problemlerin loglar ve monitoring ile izlenebilir olmasıdır.

Delphi ile PostgreSQL: tip ve göç konsepti temizse iyi yönetilir

PostgreSQL mit Delphi UUID, zaman damgaları, JSON alanları gibi tip eşlemeleri, indeksler ve şema-migrasyonları düzgün ele alındığında sağlamdır. Özellikle portallar çok sayıda filtreli liste sorgusu üretecektir. Filtreleme, paging ve sıralama server tarafında uygulanmalıdır, böylece gereksiz büyük veri transferleri engellenir. Bu hem yükü azaltır hem de kullanıcı deneyimini iyileştirir, masaüstünün yavaşlamasına yol açmadan.

İşletim, dağıtım ve izleme: Delphi arka uçlar için portal olgunluğu sağlamak

Bir portal genellikle sürekli erişilebilir olmalı ve bu da onu saf masaüstüne göre daha işletme yoğun yapar. Yöneticiler için burada iyi bir mimarinin getirdiği fayda hemen görülür: izlenebilir deploy’lar, net gözlemlenebilirlik (loglar/metrikler) ve tanımlı bakım pencereleri sayesinde.

Windows-Service veya Linux-Service: işletme modeli belirleyicidir

Bir Delphi-servis Windows- und Linux-Services veya bir Linux daemon olarak işletilebilir. İşletim sistemi yerine önemli olan, işletimi stabil kılan standartlardır:

• Health-Checks monitoring ve load balancer için (örn. „servis yaşıyor“ ve „veritabanı erişilebilir“).
• Yapılandırılmış logging (istek-ID, kullanıcı/tenant, çalışma süresi, durum kodları dahil) böylece destek vakaları yeniden üretilebilir.
• Yeniden derleme olmadan konfigürasyon (örn. environment değişkenleri, merkezi konfigürasyon dosyaları), böylece deploy’lar otomatik ve temiz yapılabilir.
• Rollback yeteneği net sürümler ve migration-dostu veritabanı değişiklikleri ile sağlanmalıdır.

Yük profilleri: portal „çok kısa istekler“ yerine „az sayıda uzun oturum“ değildir

Masaüstü kullanımında genellikle her kullanıcı başına daha uzun çalışma dönemleri oluşurken, portallar birçok kısa, paralel istek üretir. Tipik teknik önlemler şunlardır:

• kesin paging, server tarafı filtreleme ve sınırlı cevap büyüklükleri
• temel veriler ve nadiren değişen sorgular için caching
• uzun işler için asenkron görevler (dışa aktarımlar, rapor paketleri)
• rate-limitler ve kötüye kullanım korumaları

Karar vericiler için merkezi nokta: Performans bir „son aşamada ince ayar“ değil, API tanımının bir parçasıdır (cevap büyüklükleri, timeout’lar, arka plan işlem kuralları).

Big-Bang olmadan modernizasyon: beş adımlı sağlam yol

Tam bir yeniden inşa nadiren gerekli ve sıklıkla risklidir, çünkü süreç bilgisi Delphi-istemcide saklıdır. Her aşaması üretken olarak kullanılabilen ve işletmeyi tehlikeye atmayan bir yaklaşımın işe yaradığını görüyoruz.

1) Envanter çıkışı: süreçler, veri mülkiyeti, entegrasyonlar

Maskelerle başlamayın; kullanım senaryoları ile başlayın: Hangi akışlar porta[l]a taşınmalı? Hangi verileri harici bir kullanıcı görebilir veya değiştirebilir? ERP, DMS veya CRM ile hangi arayüzler mevcut? Bunlardan gerçek değer üreten öncelikli bir API listesi çıkar.

2) Servis temellerini tanımlamak: Auth, hata formatı, logging, versiyonlama

Bu temel ilerideki sürdürülebilirliği belirler. Erken dönemde kimlik doğrulama/yetkilendirme standartları, tutarlı bir hata formatı, istek korelasyonu, API versiyonlama ve telemetri üzerinde anlaşın. Bu, portal ekibi, backend ekibi ve işletme arasındaki sürtüşmeyi azaltır.

3) İlk portal yolu uçtan uca teslim etmek

Net sınırları olan bir süreç seçin (ör. belge alanı veya durum sorgulama). Önemli olan tüm zincirin çalışır olmasıdır: login, yetki kontrolü, API, UI, logging, monitoring, işletim. Organizasyon böylece erken dönemde hangi standartların günlük hayatta işe yaradığını görür.

4) Masaüstünü hedefli bağlamak: kritik yazma yollarını servisler üzerinden geçirmek

Servisler stabil olduğunda seçilmiş masaüstü fonksiyonlarını çekirdeğe kaydırın: özellikle durum değişiklikleri, onaylar veya merkezi doğrulamalar. Masaüstü performanslı kalır, ama kurallar daha tutarlı hale gelir ve doğrudan DB yazma erişimi kademeli olarak azalır.

5) Konsolidasyon: çift kurallar ve istisnai yolları azaltmak

Zamanla aksi takdirde „iki sistem“ oluşur. Düzenli konsolidasyon planlayın: hangi kurallar çiftlenmiş? Portal nerede masaüstü-servisi kullanabilir? Hangi raporlar merkezi olarak üretilmeli? Hedef kontrol edilebilir bir platform, dogmatik bir yaklaşım değil.

İşletme perspektifinden tipik tuzaklar — ve nasıl önlersiniz

Kurum kuralları portalda yeniden yazılıyor

Bu sapmalara ve destek vakalarına yol açar. Karşı önlem: Use-Case-API’ler ile sunucu tarafı doğrulamaları, net hata dönüşleri ve mümkünse ortak mesleki test senaryoları.

Masaüstü ile portal arasında belirsiz veri mülkiyeti

Her iki istemci de „her şeyi“ değiştirebiliyorsa çakışmalar doğar. Karşı önlem: durum modeli, tanımlı sorumluluklar ve çakışan değişiklikler için Optimistic Concurrency.

Güvenlik sonradan eklenmiş bir eklenti gibi ele alınıyor

Müşteri portalında SSO, tenant kontrolleri, güvenli dosya indirmeleri ve audit en baştan gereklidir. Sonradan eklemek daha maliyetli ve güvenlik boşlukları riskini artırır.

İşletimde şeffaflık eksikliği

İstek ID’leri, yapılandırılmış loglar ve health-check’ler olmadan hata bulma dedektiflik olur. Karşı önlem: gözlemlenebilirlik ilk servis sürümlerinin zorunlu bir parçası olmalıdır.

Sonuç: Bir servis çekirdeği masaüstünün gücünü portal erişimiyle birleştirir

Delphi-masaüstü ile web-portal kombinasyonu, mevcut çekirdek süreçleri korurken aynı zamanda dış işbirliğini mümkün kılmanın birçok şirketteki en gerçekçi yoludur. Önemli olan iki ayrı dünya işletmek değil, bir bağlayıcı servis çekirdeği oluşturmaktır: Use-Case-API’ler, temiz yetkilendirme, izlenebilir durumlar, kontrollü veri yolları ve logging, monitoring ile planlanabilir deployment’lar içeren bir işletim modeli.

Böylece ara hedeflerle bir modernizasyon ortaya çıkar: Masaüstü üretken kalır, portal erken değer sağlar ve mimari adım adım daha tutarlı ve sürdürülebilir hale gelir.

Mesleki bağlamda Delphi Modernisierung da önemli bir rol oynar; entegrasyonlar, veri akışları ve devam eden geliştirme temiz şekilde bir araya getirilmelidir.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.