Łączenie Delphi Desktop i portali internetowych: architektura, interfejsy i modernizacja bez zakłóceń

Wielu przedsiębiorstwom „centrum operacyjne” rozrosło się przez lata jako Delphi-aplikacja desktopowa: klient VCL, głęboka wiedza procesowa, szybkie wprowadzanie danych, ścieżki drukowania i raportowania, specjalistyczny sprzęt oraz często bezpośredni dostęp do bazy danych w LAN. Jednocześnie rosną oczekiwania dotyczące samoobsługi i współpracy zewnętrznej: klienci chcą sprawdzać statusy zleceń, wymieniać dokumenty lub zgłaszać reklamacje – bez VPN, bez wdrożenia klienta i bez lokalnych instalacji.

Delphi Desktop i portale WWW łączyć oznacza w praktyce scalić te dwa światy tak, aby eksploatacja, bezpieczeństwo i spójność danych pozostawały pod kontrolą. Kluczowe nie jest „odtwarzanie” formularzy w przeglądarce, lecz architektura, która wyraźnie oddziela procesy, uprawnienia i ścieżki danych oraz pozwala obu frontendom pracować według wspólnych reguł. Zysk to ścieżka modernizacji bez Big-Bang: desktop pozostaje produktywny, podczas gdy portal webowy rośnie w kontrolowany sposób.

Ten artykuł jest adresowany do kierownictwa IT, administratorów i technicznych osób odpowiedzialnych za projekty. W centrum uwagi są skutki dla eksploatacji, administracji, interfejsów, bezpieczeństwa, przechowywania danych i migracji – mniej szczegółów dotyczących frameworków. Otrzymają Państwo praktyczne wzorce, kryteria decyzyjne oraz typowe pułapki wraz ze środkami zaradczymi.

Dlaczego „Portal zamiast Desktopu” rzadko jest realistyczny

W środowiskach B2B istnieje wiele powodów, dla których klient desktopowy nadal ma sens. Administratorzy doświadczają tego często wprost: portal jest idealny dla użytkowników rozproszonych, ale pewne zadania pozostają w desktopie bardziej efektywne lub w ogóle możliwe do wykonania.

Mocne strony desktopu, które liczą się w codziennej pracy

• Złożone wprowadzanie danych z bardzo zwartymi formularzami, obsługą klawiatury, dużymi widokami tabel i szybkim przełączaniem między rekordami.
• Periferia i lokalne integracje takie jak drukarki etykiet, skanery, urządzenia szeregowe lub specjalne komponenty Windows.
• Wydajność bliska LAN, gdy przetwarzane są duże wolumeny danych lub proces wymaga bardzo niskich opóźnień.
• Ugruntowane workflowy z wieloma przypadkami szczególnymi, gdzie 1:1 przeniesienie do portalu wiąże się początkowo z dużym ryzykiem.

Mocne strony portalu, które odpowiadają na nowe wymagania

• Dostęp zewnętrzny dla klientów, dostawców lub partnerów, bez konieczności wdrażania klienta.
• Centralne sterowanie (wersje, funkcje, uprawnienia) z wyraźną krawędzią zewnętrzną.
• Niezależność urządzeń (przeglądarka, użycie mobilne) dla służb terenowych i zarządu.
• Kierunkowe otwieranie procesów takie jak zapytania statusu, przesyłanie plików, zatwierdzenia lub trasy ticketowe.

W kombinacji leży wartość: desktop pozostaje narzędziem dla ról wewnętrznych, portal staje się kontrolowanym dostępem dla grup zewnętrznych. Aby nie rozjechały się dwie równoległe „prawdy”, potrzebne jest łączące jądro.

Gdy łączą Państwo Delphi Desktop i portale WWW: trzy architektury docelowe

Decyzja architektoniczna dotyczy przede wszystkim odpowiedzialności: gdzie leży reguła biznesowa? Kto może modyfikować dane? Która warstwa jest „Single Source of Truth“ (czyli decydującym źródłem reguł i stanów)? Dla technicznych decydentów ważne jest: wybór ma bezpośrednie konsekwencje dla eksploatacji, diagnostyki, zarządzania wydaniami i bezpieczeństwa.

Wariant A: portal jako uzupełnienie przez REST-API, desktop pozostaje wiodący

Portal obsługuje wybrane przypadki użycia, zwykle „odczyt i inicjowanie”: statusy, dokumenty, zatwierdzenia, proste wprowadzania. W tym celu wprowadza się Delphi REST-API lub oddzielny REST-Server. Aplikacja desktopowa może początkowo dalej uzyskiwać bezpośredni dostęp do bazy danych.

Korzyść operacyjna: szybkie rozpoczęcie, niewielkie ingerencje w desktop, dobre dla pierwszej wartości portalu.

Punkt ryzyka: istnieją dwa kanały dostępu do danych (Desktop → DB bezpośrednio, Portal → API). Jeśli reguły biznesowe są tylko w desktop, pojawią się niespójności. Środkiem zaradczym jest uruchamianie funkcji portalu tam, gdzie reguły są proste i możliwe do odwzorowania po stronie serwera (np. udostępnianie dokumentów, zapytania statusu, zdefiniowane akcje zatwierdzające).

Wariant B: rdzeń usług jako wspólna warstwa procesowa (zalecany przy pracy równoległej)

W tym podejściu stopniowo przenoszą Państwo logikę biznesową z desktopu do usług. Desktop i portal korzystają z tych samych endpointów. Desktop staje się silniejszym Rich Clientem (UI, integracje lokalne), reguły i walidacje znajdują się po stronie serwera.

Korzyść operacyjna: centralne miejsce dla uprawnień, audytu, logiki statusów i walidacji; spójne zachowanie we wszystkich frontendach.

Wysiłek: większy na początku, ponieważ trzeba starannie zaplanować standardy API, formaty błędów, wersjonowanie, monitoring i wdrożenia. W zamian później nakład pracy spada, bo istnieje mniej specjalnych ścieżek.

Wariant C: portal prowadzi, desktop pozostaje klientem specjalnym

Ten wariant ma sens, gdy przeglądarka ma strategicznie stać się standardowym wejściem (np. silnie rozproszona organizacja), ale desktop pozostaje dla ról wymagających specjalnego sprzętu lub wydajnego zbierania danych. Rdzeń usług musi wtedy być szczególnie stabilny i skalowalny.

Layer-3 architektura jako zrozumiała wytyczna

Niezależnie od wariantu pomaga Layer-3 Architektur: (1) prezentacja (desktop/portal), (2) warstwa aplikacji i domeny (use-cases, reguły), (3) infrastruktura (baza danych, magazyn plików, messaging, systemy zewnętrzne). Dla administratorów jest to istotne, ponieważ granice operacyjne stają się czytelne: co jest „problemem frontendu”, co jest „problemem serwisów”, co leży w bazie danych lub w magazynie? To rozdzielenie skraca diagnostykę i redukuje skutki uboczne przy wdrożeniach.

Ujęcie praktyczne: jak desktop i portal dzielą ten sam proces

Największym wyzwaniem rzadko jest „zbudowanie portalu”, a pytanie: jak desktop i portal dzielą odpowiedzialności w tym samym procesie, bez podwójnego implementowania reguł? W praktyce szczególnie istotne są trzy wzorce.

1) Use-Case-API zamiast API tabelowych lub CRUD

Częstą ślepą uliczką jest API, które jedynie odwzorowuje tabele bazy danych na zewnątrz („Create/Read/Update/Delete”). Wtedy reguły trzeba odtwarzać w portalu, a desktop pozostaje przy własnych regułach. Lepsze są Use-Case-API: endpointy opisują fachowe akcje takie jak „utwórz reklamację”, „zatwierdź zlecenie”, „prześlij dokument”, „potwierdź status dostawy”.

Efekt w eksploatacji jest odczuwalny: walidacje odbywają się po stronie serwera, komunikaty o błędach są powtarzalne, a oba klienty (desktop i portal) uruchamiają ten sam przebieg przez tę samą logikę.

2) Opanowanie konfliktów i powtórzeń

Z pojawieniem się portalu rośnie prawdopodobieństwo równoległych modyfikacji i powtarzających się żądań (np. z powodu timeoutów, retryów lub podwójnych kliknięć użytkownika). Pomocne są trzy koncepcje, bez wprowadzania „stałych blokad”:

• Idempotencja: krytyczne akcje są zaprojektowane tak, aby powtórzenie miało ten sam skutek i nic nie było wykonywane podwójnie. W praktyce realizuje się to często przez unikalny identyfikator żądania (Idempotency Key).
• Optimistic Concurrency: rekord nosi informację o wersji (np. „Row Version”). Przy zmianach serwis sprawdza, czy wersja nadal pasuje i zwraca konflikty w czytelny sposób.
• Krótkie transakcje: zamiast „blokować wszystko” zapisy są krótkotrwałe. Długotrwałe prace (np. eksporty, pakiety raportów) są wykonywane asynchronicznie.

Dla technicznych decydentów istotne jest: mechanizmy te redukują obciążenie wsparcia, ponieważ zjawiska typu „zrobiło się dwukrotnie” czy „moja zmiana zniknęła” pojawiają się znacznie rzadziej.

3) Czyste modelowanie stanów i przekazywania

Jeżeli desktop obsługuje złożone przypadki, a portal „tylko” dostarcza wnioski lub wstępne etapy, potrzebne są zdefiniowane przejścia statusów. Praktyczny podział to: portal tworzy lub uzupełnia zgłoszenia w jasno ograniczonych obszarach statusowych (np. „złożone”), desktop obsługuje przypadki specjalne, a rdzeń usług decyduje i rejestruje zmiany statusów. W ten sposób unikają Państwo sytuacji, w której klient portalu pośrednio „niepoprawnie konfiguruje” procesy.

Dane i dokumenty: często niedoceniany obszar integracji

Prawie każdy portal wprowadza operacje plikowe: uploady, zaświadczenia, listy przewozowe, obrazy, wydruki PDF. Dla administratorów to kluczowy punkt, ponieważ wpływa na backup, uprawnienia, skanowanie antywirusowe, koszty storage i wydajność.

Gdzie przechowywać pliki: baza danych, plikowy share czy obiektowy storage?

Są trzy powszechne opcje przechowywania, każda prowadzi do innej rzeczywistości operacyjnej:

• Baza danych (BLOB): dobre, gdy transakcje muszą być ściśle powiązane i backup/restore ma obejmować wszystko w jednym pakiecie. Minusem są często większe bazy danych i dłuższe okna backupu.
• Filesystem/Share: typowe on-prem, dobrze integruje się z istniejącymi politykami backupu. Ważne są jasne uprawnienia i warstwa API kontrolująca dostęp.
• Object-Storage: sensowne przy skalowaniu, regułach lifecycle lub gdy dostęp zewnętrzny ma być technicznie odizolowany. Wymaga świadomego modelu kluczy i uprawnień.

Niezależnie od miejsca przechowywania obowiązuje zasada: portal nie powinien pobierać plików „bezpośrednio” z share. Lepiej kontrolowany download przez endpointy serwisowe z weryfikacją uprawnień, rejestracją i opcjonalnymi czasowo ograniczonymi URL-ami do pobrania.

PDF-y i raporty: po stronie serwera zamiast dublowania

Delphi-aplikacje desktopowe często mają ugruntowane ścieżki drukowania i raportowania. Portale potrzebują często tych samych treści jako PDF. Zamiast utrzymywać dwie implementacje warto mieć centralne generowanie dokumentów w rdzeniu usług: szablony, wersjonowanie i formaty wyjściowe po stronie serwera; desktop i portal konsumują wynik. Dla eksploatacji to przynosi jasne korzyści: odtwarzalne wydruki, jednolite przechowywanie i mniejsze uzależnienie od instalacji desktopowych.

REST-Server i usługi: Delphi, C# czy architektura hybrydowa

Decyzja „Delphi czy C#” w firmach dotyczy mniej ideologii, a bardziej umiejętności zespołu, środowiska operacyjnego i utrzymania. W wielu otoczeniach realistyczna jest architektura mieszana, pod warunkiem że odpowiedzialności są czytelnie podzielone.

Delphi jako platforma usługowa: sensowne przy istniejącej logice fachowej

Jeżeli logika fachowa i dostęp do danych są już solidnie osadzone w Delphi, implementacja REST-Server opartego na Delphi może być efektywna. Dla administratorów i decydentów istotne jest: serwer to nie „desktop w trybie ciągłym”. Produktywna usługa potrzebuje jasnej konfiguracji, rozsądnych timeoutów, uporządkowanych logów, health-checków i powtarzalnego procesu deploymentu.

Również podłączenie do danych powinno zostać zmodernizowane, jeśli w grze są stare sterowniki lub BDE. BDE-Ablösung i przejście na nowoczesne mechanizmy dostępu do danych zmniejsza awaryjność w eksploatacji i ułatwia deployment, bo potrzeba mniej komponentów legacy do instalacji i utrzymania.

C# services w ekosystemie portalu: często ze względu na hosting i identity

Jeśli portal powstaje w krajobrazie zdominowanym przez .NET, C# Services są często naturalnym wyborem – nie tylko ze względu na integrację Identity, istniejące standardy eksploatacji i hosting za Microsoft IIS lub w platformach konteneryzowanych. Kluczowe jest, aby unikać podwójnych implementacji: albo logika fachowa zostaje w Delphi-serwisach, a C# przejmuje tematy brzegowe (np. orkiestracja specyficzna dla portalu), albo planuje się kontrolowaną migrację logiki do .NET z jasnymi granicami domenowymi.

API-Gateway: element porządkujący, ale nie obowiązkowy

API-Gateway może skupić centralne funkcje (routing, rate-limity, logowanie, autentykacja). Dla mniejszych startowych architektur często wystarcza spójne API ze zunifikowanymi standardami. Gdy jednak pojawia się wiele serwisów i grup użytkowników, gateway pomaga utrzymać zewnętrzną krawędź stabilną i egzekwować polityki centralnie.

Uwierzytelnianie i uprawnienia: od wewnętrznego desktopu do zewnętrznego świata portalu

Z pojawieniem się portalu zmienia się krajobraz użytkowników: obok użytkowników wewnętrznych pojawiają się konta zewnętrzne, role i wielość tenantów. To rodzi wymagania dotyczące identity, uprawnień i audytowalności. Dla administratorów istotne jest, że systemy tożsamości i model ról są później trudne do zmiany.

SSO z SAML 2.0 lub OIDC: mniej pracy administracyjnej, lepsza kontrola

W konfiguracjach B2B powszechne jest SAML 2.0 (Single Sign-on przez Identity Provider), ponieważ firmy chcą używać istniejących tożsamości. OIDC (OpenID Connect) jest również rozpowszechnione, zwłaszcza na nowocześniejszych platformach. Klasyczne loginy użytkownik/hasło są możliwe, ale generują dodatkowe wymagania dotyczące polityk haseł, MFA, procesów resetu i wsparcia.

Architektonicznie istotne: uwierzytelnianie (kto jesteś?) i autoryzacja (co możesz?) muszą być sprawdzane po stronie serwera – nie w frontendzie portalu.

Multi-tenancy i model ról: nie dodawać „później”

Portal klienta praktycznie zawsze wymaga separacji tenantów: klient widzi tylko swoje dane. To musi być odwzorowane w rdzeniu usług, najlepiej przez:

• Claims w tokenie (np. Tenant-ID, role, odniesienie do umowy), aby serwisy mogły podejmować decyzje.
• Sprawdzanie na poziomie rekordu (Row-Level-Checks w logice fachowej), nie tylko „ukrywanie menu”.
• Ścieżki audytu dla istotnych działań (kto, co, kiedy), plus korelacja przez Request-ID dla analizy błędów.

Desktop również może – jeśli jest pożądane – pracować z tokenami wobec tego samego stosu Identity. Redukuje to specjalne ścieżki i ułatwia odtwarzalność zmian, zwłaszcza gdy portal i desktop modyfikują ten sam rekord.

Modernizacja dostępu do danych: FireDAC, PostgreSQL i kontrolowane ścieżki danych

Wiele rozwiązań desktopowych Delphi historycznie rozwinęło się z bezpośrednim dostępem do DB. Gdy pojawia się portal, staje się to tematem architektonicznym: ścieżki danych muszą być kontrolowalne, walidacje muszą działać centralnie, a wydajność musi pozostać stabilna także przy równoległym obciążeniu.

FireDAC jako podstawa utrzymywalnego dostępu do danych

BDE-Ablösung mit nativer Anbindung jest w środowiskach Delphi powszechnym standardem dostępu do nowoczesnych baz danych. Ważniejsza od samego komponentu jest unifikacja: parametryzowane zapytania, jasne granice transakcji, jednolite obsługi błędów i mierzalne czasy wykonania. Dla eksploatacji ważne jest, aby timeouty i zużycie zasobów były planowalne i aby problemy dało się prześledzić w logach i monitoringu.

PostgreSQL z Delphi: dobrze opanowalny przy czystym typ-mappingu i koncepcji migracji

PostgreSQL mit Delphi jest solidny, jeśli mapowanie typów (np. UUID, znaczniki czasu, pola JSON), indeksy i migracje schematu są odpowiednio traktowane. Portale generują szczególnie dużo filtrujących zapytań listowych. Dlatego filtry, stronicowanie i sortowanie powinny być realizowane po stronie serwera, żeby nie przesyłać niepotrzebnie dużych wolumenów danych. To zmniejsza obciążenie i poprawia doświadczenie użytkownika, bez pogarszania wydajności desktopu.

Eksploatacja, deployment i monitoring: wprowadzić dojrzałość portalu dla backendów Delphi

Portal zwykle musi być dostępny non-stop i jest z tego powodu bardziej wymagający operacyjnie niż sam desktop. Dla administratorów to obszar, w którym dobra architektura od razu się opłaca: przez powtarzalne deploymenty, przejrzystą obserwowalność (logi/metryki) i zdefiniowane okna konserwacyjne.

Windows-Service lub Linux-Service: decydujący jest model operacyjny

Usługa Delphi może działać jako Windows- i Linux-Services lub jako daemon Linux. Ważniejsze niż system operacyjny są standardy, które stabilizują eksploatację:

• Health-Checks dla monitoringu i load balancera (np. „usługa działa” i „baza danych osiągalna”).
• Strukturalne logowanie (wraz z Request-ID, użytkownikiem/tenantem, czasem wykonania, kodami statusu), aby przypadki wsparcia dało się odtworzyć.
• Konfiguracja bez rebuildu (np. zmienne środowiskowe, centralne pliki konfiguracyjne), aby deploymenty były automatyzowalne.
• Możliwość rollbacku przez jasne wersjonowanie i migracje bazy danych bezpieczne dla zmian.

Profile obciążenia: portal to „wiele krótkich żądań” zamiast „kilku długich sesji”

Korzystanie z desktopu generuje często dłuższe sesje pracy per użytkownik, podczas gdy portale powodują wiele krótkich, równoległych żądań. Typowe techniczne środki to:

• konsekwentne stronicowanie, filtry po stronie serwera i ograniczone rozmiary odpowiedzi
• cache dla danych referencyjnych i rzadkich zapytań
• zadania asynchroniczne dla długich operacji (eksporty, pakiety raportów)
• rate-limity i mechanizmy ochrony przed nadużyciami

Dla decydentów kluczowe jest: wydajność to nie „dopieszczanie“ na końcu, lecz część definicji API (rozmiary odpowiedzi, timeouty, przetwarzanie w tle).

Modernizacja bez Big-Bang: solidna ścieżka w pięciu krokach

Pełny rebuild rzadko jest konieczny i często ryzykowny, ponieważ wiedza procesowa tkwi w kliencie Delphi. Sprawdzone podejście to etapowanie, w którym każde stadium jest produkcyjnie użyteczne i nie zagraża eksploatacji.

1) Inwentaryzacja: procesy, suwerenność danych, integracje

Nie zaczynajcie Państwo od formularzy, lecz od use-case’ów: które procesy mają trafić do portalu? Jakie dane może zewnętrzny użytkownik widzieć lub zmieniać? Jakie interfejsy istnieją do ERP, DMS czy CRM? Z tego powstaje priorytetyzowana lista API, które dają realną wartość.

2) Zdefiniować podstawy usług: auth, format błędów, logowanie, wersjonowanie

Ta baza przesądza o późniejszej utrzymywalności. Uzgodnijcie Państwo wcześnie standardy dla uwierzytelniania/autoryzacji, spójny format błędów, korelację żądań, wersjonowanie API i telemetrię. To redukuje tarcie między zespołem portalu, zespołem backendu i operacjami.

3) Dostarczyć pierwszą ścieżkę portalu end-to-end

Wybierzcie proces o jasnych granicach (np. obszar dokumentów lub zapytanie statusu). Ważne, aby cały łańcuch działał: login, weryfikacja uprawnień, API, UI, logowanie, monitoring, eksploatacja. Organizacja szybko zobaczy, które standardy działają w praktyce.

4) Celowe podłączenie desktopu: krytyczne ścieżki zapisu przez usługi

Gdy usługi są stabilne, przenieście wybrane funkcje desktopu: w szczególności zmiany statusów, zatwierdzenia lub centralne walidacje. Desktop pozostaje wydajny, ale reguły stają się bardziej spójne, a bezpośredni zapis do DB jest stopniowo ograniczany.

5) Konsolidacja: eliminowanie podwójnych reguł i specjalnych ścieżek

Bez tego powstaną „dwa systemy”. Planować należy regularną konsolidację: które reguły istnieją podwójnie? Gdzie portal może użyć service’ów desktopu? Które raporty powinny być generowane centralnie? Celem jest opanowalna platforma, nie dogmat.

Typowe pułapki z perspektywy eksploatacji – i jak ich unikać

Reguły są odtwarzane w portalu

To prowadzi do rozbieżności i zgłoszeń do wsparcia. Środek zaradczy: Use-Case-API z walidacjami po stronie serwera, klarownymi komunikatami o błędach i – jeśli możliwe – wspólnymi scenariuszami testów fachowych.

Niejasna suwerenność danych między desktopem a portalem

Jeśli oba klienty mogą „wszystko” zmieniać, powstają konflikty. Środek zaradczy: model statusów, zdefiniowane odpowiedzialności i Optimistic Concurrency dla konkurencyjnych zmian.

Bezpieczeństwo traktowane jako dodatek

Szczególnie przy portalu klienta SSO, kontrole tenantów, bezpieczne pobieranie plików i audyt są konieczne od początku. Później jest drożej i zwiększa ryzyko wycieków bezpieczeństwa.

Brak przejrzystości w eksploatacji

Bez Request-ID, strukturalnych logów i health-checków diagnostyka staje się pracą detektywa. Środek zaradczy: observability jako obowiązkowy element pierwszych wydań serwisów.

Wniosek: rdzeń usług łączy moc desktopu z zasięgiem portalu

Połączenie Delphi-desktopu i portalu webowego jest w wielu firmach najbardziej realistyczną ścieżką, by zachować istniejące kluczowe procesy i jednocześnie umożliwić współpracę zewnętrzną. Istotne jest, by nie prowadzić dwóch oddzielnych światów, lecz stworzyć łączący rdzeń usług: Use-Case-API, czyste uprawnienia, przejrzyste stany, kontrolowane ścieżki danych oraz model operacyjny z logowaniem, monitoringiem i planowalnymi deploymentami.

W ten sposób powstaje modernizacja z celami pośrednimi: desktop pozostaje produktywny, portal szybko dostarcza wartość, a architektura staje się krok po kroku bardziej spójna i utrzymywalna.

W obszarze fachowym ważną rolę odgrywa też Delphi Modernisierung, gdy integracje, przepływy danych i dalszy rozwój muszą ze sobą czysto współgrać.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.