Kombinace Delphi desktopu a webových portálů: architektura, rozhraní a modernizace bez přerušení

V mnoha firmách se odborné „řídicí centrum“ v průběhu let vyvinulo jako Delphi desktopová aplikace: VCL klient, hluboké procesní znalosti, rychlé zadávání dat, tiskové a reportovací toky, specializovaný hardware a často přímý přístup k databázi v LAN. Současně rostou očekávání ohledně self-service a externí spolupráce: zákazníci chtějí kontrolovat stav objednávek, vyměňovat dokumenty nebo zadávat reklamace – bez VPN, bez rolloutu desktopu a bez lokálních instalací.

Delphi Desktop a webová portály kombinovat v praxi znamená tyto dva světy tak propojit, aby provoz, bezpečnost a konzistence dat zůstaly kontrolovatelné. Rozhodující není „překopírování“ obrazovek do prohlížeče, ale architektura, která čistě oddělí procesy, práva a datové cesty a nechá obě frontendy pracovat podle společných pravidel. Ziskem je cesta modernizace bez Big-Bangu: desktop zůstává produktivní, zatímco webové portál roste kontrolovaně.

Tento článek je určen IT vedení, administrátorům a technickým projektovým odpovědným. V centru pozornosti jsou dopady na provoz, administraci, rozhraní, bezpečnost, uchování dat a migraci – méně podrobností o frameworku. Dostanete praktické vzory, rozhodovací kritéria a typické úskalí včetně protirusení.

Proč je „portál místo desktopu“ zřídka realistické

V B2B prostředích existuje mnoho důvodů, proč desktopový klient nadále dává smysl. Administrátoři to často zažívají konkrétně: portál je ideální pro rozptýlené uživatele, ale některé úlohy jsou v desktopu efektivnější nebo jsou tam vůbec možné.

Silné stránky desktopu, které v praxi rozhodují

• Složitý sběr dat s velmi hustými formuláři, ovládáním z klávesnice, velkými tabulkovými pohledy a rychlým přepínáním mezi záznamy.
• Periferie a lokální integrace jako tiskárny štítků, skenery, sériová zařízení nebo speciální Windows komponenty.
• LAN-blízký výkon, když se zpracovává velké množství dat nebo proces vyžaduje extrémně nízké latence.
• Vyvinuté workflow s mnoha výjimkami, u kterých by 1:1 port do webu zpočátku představoval vysoké riziko.

Silné stránky portálu, které pokrývají nové požadavky

• Externí přístup pro zákazníky, dodavatele nebo partnery, aniž by bylo nutné nasazovat klienta.
• Centrální řiditelnost (verze, funkce, oprávnění) s jasnou vnější hranicí.
• Nezávislost na zařízení (prohlížeč, mobilní použití) pro terénní pracovníky a management.
• Cílené otevření procesů jako dotazy na stav, nahrávání, schvalování nebo ticketové toky.

V kombinaci je přínos zřejmý: desktop zůstává nástrojem pro interní role, portál se stává kontrolovaným vstupem pro externí uživatelské skupiny. Aby se nestaly dvě paralelní „pravdy“, je potřeba spojující jádro.

Když kombinujete Delphi Desktop a web-portály: tři cílové architektury

Při rozhodování o architektuře jde především o odpovědnosti: Kde leží odborné pravidlo? Kdo smí data měnit? Která vrstva je „Single Source of Truth“ (tedy rozhodující zdroj pravidel a stavů)? Pro technické rozhodovatele je důležité: volba má přímé dopady na provoz, ladění chyb, release-management a bezpečnost.

Varianta A: portál jako doplněk přes REST-API, desktop zůstává vedoucí

Portál obsluhuje vybrané use-casy, typicky „čtení a iniciování“: stav, dokumenty, schválení, jednoduché zápisy. K tomu se zřizuje Delphi REST-API nebo samostatný REST-server. Desktopová aplikace může zpočátku nadále přistupovat přímo do databáze.

Provozní výhoda: rychlé nasazení, malé zásahy do desktopu, vhodné pro první hodnotu portálu.

Rizikový bod: existují dva datové kanály (Desktop → DB přímo, Portál → API). Pokud jsou obchodní pravidla pouze v desktopu, vznikají nekonzistence. Jako opatření by měly portálové funkce začínat tam, kde jsou pravidla jednoduchá a lze je serverově zobrazit (např. zpřístupnění dokumentů, dotaz na stav, definované akce schválení).

Varianta B: servisní jádro jako společná procesní vrstva (doporučeno při paralelním provozu)

Zde postupně přesouváte obchodní logiku z desktopu do servisů. Desktop i portál používají stejné endpointy. Desktop se více mění na Rich Client (UI, lokální integrace), pravidla a validace leží serverově.

Provozní výhoda: centrální místo pro práva, audit, stavovou logiku a validace; konzistentní chování napříč frontendy.

Náročnost: vyšší na začátku, protože je potřeba jasně naplánovat API standardy, formáty chyb, verzování, monitoring a nasazení. Návrat v podobě nižšího úsilí později je však výrazný, protože ubývá speciálních cest.

Varianta C: portál vede, desktop zůstává jako specializovaný klient

Tato varianta dává smysl, pokud má být prohlížeč strategicky standardním přístupem (např. velmi rozptýlená organizace), přičemž desktop zůstává pro vybrané role s speciálním hardwarem nebo vysokovýkonným sběrem dat. Servisní jádro musí být zvlášť stabilní a škálovatelné.

Layer-3 architektura jako srozumitelná vodítko

Nezávisle na variantě pomůže Layer-3 architektura: (1) prezentace (desktop/portál), (2) aplikační a doménová vrstva (use-casy, pravidla), (3) infrastruktura (databáze, úložiště souborů, messaging, externí systémy). Pro administrátory je to důležité, protože hranice provozu se vyjasní: co je „problém frontendu“, co je „problém servisu“, co leží v databázi nebo storage? Toto oddělení zkracuje hledání chyb a snižuje vedlejší dopady při deploymentech.

Praktická stránka: jak desktop a portál sdílejí tentýž proces

Největší výzvou není obvykle „postavit portál“, ale otázka: jak si desktop a portál rozdělí odpovědnosti ve stejném procesu, aniž by se pravidla duplikovala? V praxi jsou zvlášť relevantní tři vzory.

1) Use-Case-API místo tabulkových nebo CRUD-API

Častou slepou uličkou je API, které jen vystavuje databázové tabulky („Create/Read/Update/Delete“). Pak musí být pravidla v portálu přepsána a desktop si zachovává vlastní logiku. Vhodnější jsou Use-Case-API: endpointy popisují odborné akce jako „vytvořit reklamaci“, „uvolnit objednávku“, „nahrát dokument“, „potvrdit stav dodávky“.

Efekt v provozu je znatelný: validace probíhají serverově, chybové hlášky jsou reprodukovatelné a oba klienti (desktop i portál) spouštějí stejný průběh přes stejnou logiku.

2) Řízení konfliktů a opakovaných požadavků

S portálem roste pravděpodobnost paralelních změn a opakovaných requestů (např. kvůli timeoutům, retry logice nebo dvojkliku uživatele). Pomáhají tři koncepty, aniž by bylo nutné zavádět „trvalé zámky“:

• Idempotence: kritické akce jsou navrženy tak, že opakování má stejný efekt a nic se neprovede dvakrát. Prakticky se to často řeší jednoznačným ID požadavku (Idempotency Key).
• Optimistic Concurrency: záznam nese informaci o verzi (např. „Row Version“). Při změnách servis ověří, zda se verze shoduje, a konflikty vrátí srozumitelně.
• Krátké transakce: místo „vše zamknout“ jsou zápisy drženy krátce. Dlouhé práce (např. exporty, balíčky reportů) běží asynchronně.

Pro technické rozhodovatele je důležité: tyto mechanismy snižují nároky na podporu, protože se výrazně omezí chybové vzory typu „stalo se to dvakrát“ nebo „mění se mi moje úprava“.

3) Čisté modelování stavů a předání

Když desktop řeší složité případy a portál jen podává žádosti nebo představy, potřebujete definované stavové přechody. Praktický návrh je: portál vytváří nebo doplňuje případy v jasně omezených stavech (např. „podáno“), desktop zpracovává specializované případy a servisní jádro rozhoduje a protokoluje přechody stavů. Tím zabráníte tomu, aby portálový klient nepřímo „konfiguroval“ procesy na nefunkční stav.

Data a dokumenty: často podceňovaná integrační oblast

Takřka každý portál přináší operace se soubory: nahrávání, doklady, dodací listy, obrázky, PDF výstupy. Pro administrátory je to klíčové, protože to ovlivňuje zálohování, oprávnění, antivirovou kontrolu, náklady na storage a výkon.

Kde mají soubory ležet: databáze, fileshare nebo objektové úložiště?

Existují tři běžné možnosti ukládání, z nichž každá přináší jinou provozní realitu:

• Databáze (BLOB): vhodné, když musí být transakce přísně vázané a backup/restore má být v jednom balíku. Nevýhodou jsou často větší databáze a delší okna zálohování.
• Filesystem/Share: typické on-prem, dobře integrovatelné do stávajících zálohovacích konceptů. Důležité jsou jasná oprávnění a API vrstva, která přístup kontroluje.
• Objekt-Storage: smysluplné při škálování, životních cyklech nebo pokud mají být externí přístupy technicky čistě odděleny. Vyžaduje promyšlený model klíčů a oprávnění.

Nezávisle na místě úložiště platí: portál by neměl soubory „stahovat přímo ze share“. Lepší je kontrolované stažení přes servisní endpointy s ověřením práv, protokolováním a volitelnou časově omezenou URL pro stažení.

PDF a reporty: generovat serverově místo zdvojení

Delphi desktopové aplikace často mají vyvinuté tiskové a reportovací trasy. Portály často potřebují ty samé výstupy jako PDF. Místo udržování dvou implementací se vyplatí centrální generování dokumentů v servisním jádru: šablony, verzování a výstupní formáty na serveru; desktop i portál konzumují výsledek. Pro provoz to přináší jasné výhody: sledovatelné výstupy, jednotné uložení a menší závislost na desktopových instalacích.

REST-server a služby: Delphi, C# nebo hybridní architektura

Při rozhodování „Delphi nebo C#“ nejde v podniku tolik o ideologii jako o schopnosti týmu, provozní prostředí a udržovatelnost. V mnoha prostředích je realistická hybridní architektura, pokud jsou odpovědnosti čistě rozdělené.

Delphi jako servisní platforma: smysluplné při existující odborné logice

Pokud odborná logika a přístup k datům již existují robustně v Delphi, může být Delphi-based REST-server efektivní. Pro administrátory a rozhodovatele je důležité: provoz serveru není „desktop v nonstop běhu“. Produktivní servis potřebuje jasnou konfiguraci, vhodné timeouty, strukturované logy, health-checky a reprodukovatelné nasazení.

Také napojení na data by mělo být modernizováno, pokud se stále používají staré ovladače nebo BDE. BDE-Ablösung a přechod na moderní datové přístupy snižují provozní poruchovost a usnadňují nasazení, protože se instaluje a spravuje méně legacy komponent.

C# služby v portálovém ekosystému: často kvůli hostingu a identity

Pokud portál vzniká v .NET-dominantním prostředí, jsou C# služby často přirozenou volbou – mimo jiné kvůli integraci identity, stávajícím provozním standardům a hostingu za Microsoft IIS nebo v kontejnerových platformách. Důležité je vyvarovat se duplicitní implementace: buď zůstane odborná jádrová logika v Delphi-servisech a C# řeší edge témata (např. portálově specifickou orchestraci), nebo plánujete kontrolovanou migraci logiky do .NET s jasnými hranicemi odpovědnosti oboru.

API-Gateway: prvek pořádků, ale není nutností

API-Gateway může centralizovat funkce (routing, rate-limits, logging, autentizace). Pro menší start-architektury často postačí konzistentní API s jednotnými standardy. Jakmile ale funguje víc služeb a více skupin uživatelů, gateway pomůže udržet vnější hranici stabilní a centralizovat politiky.

Autentizace a oprávnění: od interního desktopu do externí portálové reality

S portálem se mění uživatelská krajina: vedle interních uživatelů přibudou externí účty, role a tenanty. Z toho vyplývají požadavky na identity, oprávnění a auditovatelnost. Pro administrátory je to důležité, protože identity systémy a role se později obtížně mění.

SSO pomocí SAML 2.0 nebo OIDC: méně práce pro adminy, lepší kontrola

V B2B nasazeních je rozšířený SAML 2.0 (Single Sign-on přes Identity Provider), protože firmy chtějí využít stávající identity. OIDC (OpenID Connect) je rovněž běžný, zejména v modernějších platformách. Klasické uživatel/heslo přihlašování je možné, ale znamená další nároky na politiku hesel, MFA, reset procesy a podporu.

Důležité pro architekturu: autentizace (kdo jsi?) a autorizace (co smíš?) musí být ověřovány serverově – ne v portálovém frontendu.

Multitenancy a model rolí: nedoplňovat „později“

Kundenportal prakticky vždy vyžaduje oddělení tenantů: zákazník vidí jen svá data. To musí být řešeno v servisním jádru, ideálně přes:

• Claims v tokenu (např. Tenant-ID, role, vztah ke smlouvě), aby služby mohly rozhodovat.
• Datově orientované kontroly (Row-Level-Checks) ve fachlogice, ne jen „skrytí menu“.
• Audit-traily pro důležité akce (kdo, co, kdy) plus korelace přes Request-ID pro analýzu chyb.

Desktop může – pokud je to žádoucí – také pracovat s tokeny vůči stejnému identity stacku. To snižuje speciální cesty a usnadňuje sledovatelnost změn, zvláště když portál a desktop upravují tentýž záznam.

Modernizace přístupu k datům: FireDAC, PostgreSQL a kontrolované datové cesty

Mnoho Delphi desktop řešení historicky vzniklo s přímým přístupem do DB. Jakmile přibude portál, stává se to architektonickým tématem: datové cesty musí být kontrolovatelné, validace musí fungovat centrálně a výkon musí zůstat stabilní i při paralelní zátěži.

FireDAC jako základ udržitelného přístupu k datům

BDE-Ablösung mit nativer Anbindung je v Delphi prostředích běžný standard pro přístup k moderním databázím. Důležitá není tolik samotná komponenta jako sjednocení: parametrizované dotazy, čisté transakční hranice, jednotné zpracování chyb a měřitelné doby běhu. Pro provoz je klíčové, že timeouty a spotřeba zdrojů jsou plánovatelné a že se problémy dají sledovat v logách a monitoringu.

PostgreSQL s Delphi: dobře zvládnutelné při čistém mapování typů a migračním konceptu

PostgreSQL mit Delphi je robustní, pokud je pečlivě řešeno mapování typů (např. UUID, timestampy, JSON pole), indexy a migrace schématu. Portály generují mnoho filtrovaných seznamových dotazů. Filtry, stránkování a řazení by proto měly být zpracovávány serverově, aby se nepřenášela velká datová množství zbytečně. To snižuje zátěž a zlepšuje uživatelský zážitek, aniž by desktop zpomalil.

Provoz, nasazení a monitoring: dospělost portálu pro Delphi backendy

Portál bývá obvykle trvale dostupný a je tedy provozně náročnější než čistě desktopové řešení. Pro administrátory je to oblast, kde se dobrá architektura ihned vyplatí: opakovatelné nasazení, jasná observabilita (logy/metriky) a definovaná okna údržby.

Windows-service nebo Linux-service: rozhodující je provozní model

Delphi servis může běžet jako Windows- a Linux-services nebo jako Linux daemon. Důležitější než OS jsou standardy, které činí provoz stabilním:

• Health-Checks pro monitoring a load balancer (např. „služba žije“ a „databáze dostupná“).
• Strukturované logování (vč. Request-ID, uživatel/tenant, doba běhu, status kódy), aby byly případy podpory reprodukovatelné.
• Konfigurace bez rekompilace (např. proměnné prostředí, centrální konfigurační soubory), aby nasazení šlo automatizovat.
• Schopnost rollbacku díky jasným verzím a migracím databáze bezpečným způsobem.

Profil zátěže: portál je „mnoho krátkých požadavků“ namísto „málo dlouhých relací“

Desktopové použití často generuje delší pracovní fáze na uživatele, zatímco portály vytvářejí mnoho krátkých paralelních požadavků. Typická technická opatření jsou:

• konzistentní stránkování, serverové filtry a omezené velikosti odpovědí
• caching pro referenční data a zřídka volané dotazy
• asynchronní úlohy pro dlouhé operace (exporty, balíky reportů)
• rate-limity a ochranné mechanismy proti zneužití

Pro rozhodovatele je klíčové: výkon není „doladění na konci“, ale součást definice API (velikosti odpovědí, timeouty, background zpracování).

Modernizace bez Big-Bangu: robustní cesta v pěti krocích

Kompletní přestavba je zřídka nutná a často riskantní, protože procesní znalosti jsou v Delphi klientu. Osvědčený postup je postupný přístup, kde je každá fáze produkčně použitelná a neohrožuje provoz.

1) Inventura: procesy, datová suverenita, integrace

Nezačínejte u obrazovek, ale u use-casů: které postupy mají jít do portálu? Která data může externí uživatel vidět nebo měnit? Jaká rozhraní existují k ERP, DMS nebo CRM? Z toho vznikne priorizovaný seznam API, které přinesou skutečnou hodnotu.

2) Definujte servisní základy: auth, formát chyb, logging, verzování

Tato báze rozhodne o budoucí udržovatelnosti. Dohodněte brzy standardy pro autentizaci/autorizaci, konzistentní formát chyb, korelaci požadavků, verzování API a telemetrii. To snižuje tření mezi portálovým týmem, backendovým týmem a provozem.

3) Doručte první koncovou portálovou cestu end-to-end

Vyberte proces s jasnou hranicí (např. oblast dokumentů nebo dotaz na stav). Důležité je, aby celý řetězec fungoval: login, kontrola práv, API, UI, logging, monitoring, provoz. Organizace tak brzo zjistí, které standardy v praxi fungují.

4) Cílené připojení desktopu: kritické zápisy přes služby

Jakmile jsou služby stabilní, migrací vybraných desktopových funkcí zajistěte především zápisy: zejména změny stavů, schválení nebo centrální validace. Desktop zůstane výkonný, ale pravidla budou konzistentnější a přímý DB zápis se postupně sníží.

5) Konsolidace: odstranit duplicitní pravidla a speciální cesty

Jinak vzniknou „dva systémy“. Plánujte pravidelnou konsolidaci: která pravidla existují dvakrát? Kde může portál použít desktop-service? Které reporty by měly být generovány centrálně? Cílem je ovladatelná platforma, ne dogma.

Typická úskalí z pohledu provozu – a jak jim předejít

Pravidla se v portálu přepisují

To vede k odchylkám a podpůrným případům. Protiopatření: Use-Case-API se serverovými validacemi, jasné chybové návraty a pokud možno společná fachová testovací scénáře.

Nejasná datová suverenita mezi desktopem a portálem

Pokud oba klienti „mohou vše“ měnit, vznikají konflikty. Protiopatření: stavový model, definované odpovědnosti a Optimistic Concurrency pro konkurenční změny.

Bezpečnost jako dodatečné doplnění

Zvláště u zákaznického portálu jsou SSO, tenant-checky, bezpečné stahování souborů a audit nutností od začátku. Dodatečné řešení je dražší a zvyšuje riziko bezpečnostních děr.

Chybějící transparentnost v provozu

Bez Request-ID, strukturovaných logů a health-checků se pátrání po chybách změní v detektivní práci. Protiopatření: observability jako povinná součást prvních servisních releasů.

Závěr: servisní jádro spojuje sílu desktopu s dosahem portálu

Kombinace Delphi desktopu a webového portálu je v mnoha firmách nejrealističtější cesta, jak zachovat stávající klíčové procesy a současně umožnit externí spolupráci. Rozhodující je, že neprovozujete dva oddělené světy, ale vytvoříte spojující servisní jádro: Use-Case-API, čistá oprávnění, sledovatelné stavy, kontrolované datové cesty a provozní model s loggingem, monitoringem a plánovatelnými nasazeními.

Tak vznikne modernizace s mezicíli: desktop zůstane produktivní, portál brzy přinese užitek a architektura se bude krok za krokem stávat konzistentnější a lépe udržovatelnou.

V odborném kontextu hraje roli i Delphi Modernisierung, když integrace, datové toky a další vývoj musí hladce spolupracovat.

Projekt nebo modernizační záměr probrat s Net-Base.