Combinare Delphi Desktop e portali Web: architettura, interfacce e modernizzazione senza rottura

In molte aziende la «centrale operativa» funzionale si è sviluppata nel corso degli anni come Delphi-applicazione desktop: client VCL, conoscenza di processo profonda, inserimento dati veloce, percorsi di stampa e reporting consolidati, hardware specializzato e spesso accesso diretto al database in LAN. Parallelamente crescono le aspettative su self-service e collaborazione esterna: i clienti vogliono verificare lo stato degli ordini, scambiare documenti o segnalare reclami – senza VPN, senza rollout di client e senza installazioni locali.

Combinare Delphi Desktop e portali web significa in pratica unire questi due mondi in modo che il funzionamento, la sicurezza e la coerenza dei dati rimangano gestibili. Non è decisivo «ricreare» le maschere nel browser, ma avere un’architettura che separi nettamente processi, diritti e flussi di dati e che permetta a entrambi i frontend di operare secondo regole comuni. Il vantaggio è un percorso di modernizzazione senza Big-Bang: il desktop resta produttivo mentre il portale web cresce in modo controllato.

Questo contributo è rivolto a direzione IT, amministratori e responsabili tecnici di progetto. Il focus sono gli impatti su esercizio, amministrazione, interfacce, sicurezza, persistenza dei dati e migrazione – meno dettagli sui framework. Riceverete pattern pratici, criteri decisionali e trappole tipiche con relative contromisure.

Perché «portale invece del desktop» è raramente realistico

In ambienti B2B esistono molte ragioni per cui un client desktop resta sensato. Gli amministratori lo sperimentano spesso in modo concreto: un portale è ideale per utenti distribuiti, ma certe attività rimangono più efficienti o addirittura possibili solo da desktop.

Punti di forza del desktop che contano nella pratica

• Inserimento dati complesso con maschere molto dense, uso da tastiera, ampie viste a tabella e passaggi rapidi fra record.
• Periferiche e integrazioni locali come stampanti per etichette, scanner, dispositivi seriali o componenti Windows speciali.
• Prestazioni vicino alla LAN, quando si elaborano grandi quantità di dati o un processo richiede latenze estremamente basse.
• Workflow consolidati con molti casi particolari, nei quali una porta 1:1 in un portale comporterebbe inizialmente alti rischi.

Punti di forza del portale che coprono nuove esigenze

• Accesso esterno per clienti, fornitori o partner, senza dover distribuire un client.
• Controllo centrale (versioni, funzionalità, autorizzazioni) con un confine esterno chiaro.
• Indipendenza dal dispositivo (browser, uso mobile) per forza vendita esterna e management.
• Aperture di processo mirate come consultazioni di stato, upload, autorizzazioni o flussi ticket.

Il valore sta nella combinazione: il desktop rimane lo strumento potente per ruoli interni, il portale diventa l’accesso controllato per gruppi di utenti esterni. Per evitare la creazione di due «verità» parallele serve un nucleo connettore.

Se combine Delphi Desktop e portali web: tre architetture obiettivo

La decisione architetturale riguarda soprattutto le responsabilità: dove risiede la regola di dominio? Chi può modificare i dati? Quale livello è la „Single Source of Truth“ (ossia la fonte autorevole per regole e stati)? Per i decisori tecnici è importante: la scelta ha ripercussioni dirette su esercizio, diagnostica, gestione delle release e security.

Variante A: portale come complemento tramite REST-API, desktop rimane prevalente

Il portale copre casi d’uso selezionati, tipicamente «lettura e innesco»: stati, documenti, approvazioni, inserimenti semplici. Per questo viene introdotta una Delphi REST-API o un server REST-Server separato. L’applicazione desktop può inizialmente continuare ad accedere direttamente al database.

Vantaggio operativo: avvio rapido, interventi minimi sul desktop, adatto per ottenere un valore iniziale dal portale.

Punto di rischio: esistono due vie di accesso ai dati (Desktop → DB diretto, Portale → API). Se le regole di business sono solo nel desktop, si generano incoerenze. Contromisura: far partire le funzionalità del portale dove le regole sono semplici e possono essere rappresentate lato server (es. distribuzione documenti, consultazione stato, azioni di approvazione definite).

Variante B: nucleo di servizi come strato di processo condiviso (raccomandata per funzionamento parallelo)

Qui si sposta progressivamente la logica di dominio dal desktop ai servizi. Desktop e portale usano gli stessi endpoint. Il desktop rimane un Rich Client (UI, integrazioni locali), mentre regole e validazioni sono lato server.

Vantaggio operativo: un punto centrale per diritti, audit, logica di stato e validazioni; comportamento coerente su tutti i front-end.

Impegno: maggiore all’inizio, perché bisogna pianificare standard API, formati di errore, versioning, monitoring e deployment in modo strutturato. In compenso l’impegno cala significativamente nel tempo, perché ci sono meno vie particolari.

Variante C: il portale guida, il desktop resta client specialistico

Questa variante ha senso se il browser deve diventare l’accesso standard strategico (es. organizzazioni fortemente distribuite), ma il desktop rimane per ruoli specifici con hardware specializzato o acquisizione ad alte prestazioni. Il nucleo di servizi deve allora essere particolarmente stabile e scalabile.

Architettura Layer-3 come linea guida comprensibile

Indipendentemente dalla variante, aiuta una Layer-3 Architektur: (1) presentazione (Desktop/Portale), (2) strato applicativo e di dominio (use case, regole), (3) infrastruttura (database, storage file, messaging, sistemi esterni). Per gli amministratori è importante perché i confini operativi diventano chiari: cosa è «problema frontend», cosa è «problema servizio», cosa risiede nel database o nello storage? Questa separazione abbrevia la diagnostica e riduce effetti collaterali nei deployment.

Riferimento pratico: come Desktop e Portale condividono lo stesso processo

La sfida maggiore raramente è «costruire il portale», ma piuttosto: come Desktop e Portale spartiscono responsabilità nello stesso processo senza duplicare le regole? Tre pattern sono particolarmente rilevanti in pratica.

1) Use-Case-APIs invece di API basate su tabelle o CRUD

Una via senza uscita comune è un’API che espone solo tabelle del database all’esterno („Create/Read/Update/Delete“). Allora le regole devono essere ricostruite nel portale e il desktop conserva le sue regole. Meglio adottare Use-Case-API: endpoint che descrivono azioni funzionali come „creare reclamo“, „approvare ordine“, „caricare documento“, „confermare stato di consegna“.

L’effetto in esercizio è evidente: le validazioni avvengono lato server, i messaggi di errore sono riproducibili e entrambi i client (desktop e portale) eseguono lo stesso flusso tramite la stessa logica.

2) Rendere gestibili conflitti e ripetizioni

Con un portale cresce la probabilità di modifiche parallele e di richieste ripetute (es. per timeout, retry o doppio clic degli utenti). Qui aiutano tre concetti, senza introdurre «blocchi permanenti»:

• Idempotenza: azioni critiche sono progettate in modo che una ripetizione produca lo stesso effetto e non esegua duplicati. Nella pratica questo avviene spesso tramite un identificatore univoco della richiesta (Idempotency Key).
• Concorrenza ottimistica: un record porta un’informazione di versione (es. „Row Version“). Alle modifiche il servizio verifica che la versione sia ancora valida e segnala conflitti in modo chiaro.
• Transazioni brevi: invece di «bloccare tutto» si mantengono corte le operazioni di scrittura. Lavori lunghi (es. esportazioni, pacchetti di report) sono eseguiti in modo asincrono.

Per i decisori tecnici è importante: questi meccanismi riducono l’onere del supporto, perché scenari d’errore come «è successo due volte» o «la mia modifica è sparita» si manifestano molto meno frequentemente.

3) Modellare chiaramente stati e passaggi

Se il desktop tratta casi complessi e il portale «solo» invia richieste o produce prerequisiti, servono transizioni di stato definite. Una ripartizione pratica è: il portale crea o integra processi in aree di stato chiaramente limitate (es. „inviato“), il desktop gestisce i casi speciali, il nucleo di servizi decide e registra i cambi di stato. Così si evita che il client portale possa indirettamente „configurare“ processi in modo errato.

Dati e documenti: l’area di integrazione spesso sottovalutata

Quasi ogni portale introduce operazioni su file: upload, documenti di supporto, documenti di consegna, immagini, output PDF. Per gli amministratori è un punto centrale, perché influisce su backup, autorizzazioni, scansione antivirale, costi di storage e prestazioni.

Dove risiedono i file: database, fileshare o object storage?

Ci sono tre opzioni comuni di archiviazione, che portano ognuna a una realtà operativa diversa:

• Database (BLOB): indicato quando transazioni e archiviazione devono essere fortemente accoppiate e backup/restore devono restare in un unico pacchetto. Svantaggi frequenti sono database più voluminosi e finestre di backup più lunghe.
• Filesystem/Share: tipico on-prem, ben integrabile con concetti di backup esistenti. Importante è avere autorizzazioni chiare e uno strato API che controlli l’accesso.
• Object-Storage: sensato per scalabilità, regole di lifecycle o quando accessi esterni devono essere incapsulati tecnicamente. Richiede un modello di chiavi e autorizzazioni ben definito.

Indipendentemente dal luogo di memorizzazione vale: il portale non dovrebbe caricare file «direttamente» da uno share. È preferibile un download controllato tramite endpoint di servizio con verifica dei diritti, logging e, opzionalmente, URL di download temporaneo.

PDF e report: lato server invece che duplicati

Le applicazioni Delphi desktop spesso hanno percorsi di stampa e reporting consolidati. I portali richiedono frequentemente gli stessi contenuti in PDF. Invece di mantenere due implementazioni conviene una generazione documentale centrale nel nucleo di servizi: template, versioning e formato di output sul server; desktop e portale consumano il risultato. Per l’esercizio questo porta vantaggi: output tracciabili, deposito unificato e minore dipendenza dalle installazioni desktop.

REST-Server e servizi: Delphi, C# o un’architettura mista

Nella scelta «Delphi o C#» alle aziende interessa meno l’ideologia e più la capacità del team, l’ambiente operativo e la manutenibilità. In molti contesti un’architettura mista è realistica, purché le responsabilità siano tagliate con chiarezza.

Delphi come piattaforma di servizio: sensato con logica di dominio esistente

Se la logica di dominio e l’accesso ai dati sono già solidi in Delphi, un server REST basato su Delphi può essere efficiente. Per amministratori e decisori è importante: il funzionamento server non è «desktop su strada». Un servizio produttivo richiede configurazione chiara, timeout adeguati, log strutturati, health-check e un deployment riproducibile.

Anche il collegamento ai dati dovrebbe essere modernizzato se sono ancora in gioco driver obsoleti o la BDE. Una sostituzione della BDE e la migrazione verso accessi dati moderni riducono le interruzioni in esercizio e semplificano il deployment, perché ci sono meno componenti legacy da installare e mantenere.

Servizi C# nell’ecosistema portale: comuni per hosting e identity

Se il portale nasce in un paesaggio dominato da .NET, i servizi C# sono spesso la scelta naturale – non da ultimo per integrazione identity, standard operativi esistenti e hosting dietro Microsoft IIS o in piattaforme containerizzate. Critico è evitare doppie implementazioni: o la logica centrale rimane nei servizi Delphi e C# si occupa di temi di edge (es. orchestrazione specifica del portale), oppure si pianifica consapevolmente una migrazione della logica in .NET – ma allora in modo controllato e con confini di dominio chiari.

API-Gateway: elemento di ordine, ma non obbligatorio

Un API-Gateway può centralizzare funzioni (routing, rate limits, logging, autenticazione). Per architetture di avvio più piccole spesso basta un’API coerente con standard unificati. Quando esistono più servizi e gruppi di utenti, però, un gateway aiuta a mantenere stabile la superficie esterna e ad applicare policy in modo centralizzato.

Autenticazione e autorizzazioni: dall’ambiente desktop interno al mondo portale esterno

Con un portale cambia il panorama utenti: oltre agli utenti interni arrivano account esterni, ruoli e tenant. Ciò genera requisiti su identity, autorizzazioni e auditabilità. Per gli amministratori è cruciale, perché sistemi di identity e modelli di ruolo sono difficili da cambiare in seguito.

SSO con SAML 2.0 o OIDC: meno lavoro amministrativo, migliore controllo

In setup B2B è diffuso SAML 2.0 (Single Sign-On tramite un Identity Provider), perché le aziende vogliono riutilizzare identità esistenti. OIDC (OpenID Connect) è anch’esso comune, in particolare su piattaforme più moderne. Login classici utente/password sono possibili, ma comportano ulteriore lavoro per policy password, MFA, processi di reset e supporto.

Importante per l’architettura: autenticazione (chi sei?) e autorizzazione (cosa puoi fare?) devono essere verificate lato server – non nel frontend del portale.

Multitenancy e modello di ruoli: non aggiungerli «poi»

Un portale clienti richiede praticamente sempre separazione tenant: un cliente vede solo i propri dati. Questo deve essere implementato nel nucleo di servizi, idealmente tramite:

• Claims nel token (es. Tenant-ID, ruoli, riferimento contrattuale), in modo che i servizi possano prendere decisioni.
• Verifiche per record (controlli a livello di riga nella logica di dominio), non solo «nascondere il menu».
• Audit-Trail per azioni importanti (chi, cosa, quando), più correlazione tramite Request-ID per l’analisi degli errori.

Il desktop può – se desiderato – anch’esso usare token contro lo stesso stack di identity. Questo riduce vie particolari e facilita la tracciabilità delle modifiche, soprattutto quando portale e desktop modificano lo stesso record.

Modernizzare l’accesso ai dati: FireDAC, PostgreSQL e vie dati controllate

Molte soluzioni desktop Delphi sono cresciute storicamente con accesso diretto al DB. Appena si aggiunge un portale, questo diventa una questione architetturale: i percorsi dati devono essere controllabili, le validazioni centralizzate e le prestazioni stabili anche sotto carico concorrente.

FireDAC come base per accesso dati manutenibile

Sostituzione della BDE con collegamento nativo è uno standard diffuso in ambienti Delphi per l’accesso a database moderni. Ciò che conta meno è la componente specifica e più l’uniformità: query parametrizzate, confini di transazione chiari, gestione degli errori coerente e tempi di esecuzione misurabili. Per l’esercizio è rilevante che timeout e consumo risorse diventino prevedibili e che i problemi si possano ricostruire nei log e nel monitoring.

PostgreSQL con Delphi: gestibile con un approccio di tipi e migrazioni

PostgreSQL con Delphi è robusto se il mapping dei tipi (es. UUID, timestamp, campi JSON), gli indici e le migrazioni di schema sono gestiti con cura. I portali generano molte query filtrate per liste; filtri, paging e ordinamento dovrebbero essere implementati lato server per evitare il trasferimento di grandi quantità di dati inutili. Questo riduce il carico e migliora l’esperienza utente senza rallentare il desktop.

Esercizio, deployment e monitoring: portare i backend Delphi alla maturità portale

Un portale è di norma sempre raggiungibile e quindi più esigente in esercizio rispetto a una sola soluzione desktop. Per gli amministratori questa è l’area in cui una buona architettura paga subito: deployment riproducibili, observability chiara (log/metriche) e finestre di manutenzione definite.

Windows-Service o Linux-Service: cruciale è il modello operativo

Un servizio Delphi può essere eseguito come Windows- e Linux-Services o come demone Linux. Più importante del sistema operativo sono gli standard che rendono il funzionamento stabile:

• Health-Checks per monitoring e load balancer (es. „servizio vivo“ e „database raggiungibile“).
• Logging strutturato (inclusi Request-ID, utente/tenant, tempi di esecuzione, codici di stato), per rendere riproducibili i casi di supporto.
• Configurazione senza ricompilare (es. variabili d’ambiente, file di configurazione centralizzati), per automatizzare i deployment in modo pulito.
• Possibilità di rollback tramite versioni chiare e modifiche al database compatibili con le migrazioni.

Profili di carico: il portale genera «molte richieste brevi» invece di «poche sessioni lunghe»

L’uso desktop produce spesso fasi di lavoro più lunghe per utente, mentre i portali generano molte richieste parallele e di breve durata. Misure tecniche tipiche sono:

• paging coerente, filtri lato server e dimensioni di risposta limitate
• caching per dati master e query poco frequenti
• job asincroni per attività lunghe (es. esportazioni, bundle di report)
• limiti di richiesta e meccanismi di protezione contro usi abusivi

Per i decisori è centrale: la performance non è un „fine tuning“ finale, ma parte della definizione dell’API (dimensioni di risposta, timeout, elaborazione in background).

Modernizzazione senza Big-Bang: un percorso solido in cinque fasi

Un rifacimento completo è raramente necessario e spesso rischioso, perché la conoscenza di processo risiede nel client Delphi. È collaudato un approccio in cui ogni fase è utilizzabile in produzione e non mette a rischio l’esercizio.

1) Inventario: processi, sovranità dati, integrazioni

Non iniziate dalle maschere, ma dai use case: quali flussi devono andare sul portale? Quali dati può vedere o modificare un utente esterno? Quali interfacce esistono verso ERP, DMS o CRM? Da ciò deriva una lista di API prioritarie che fornisce valore reale.

2) Definire i fondamentali di servizio: auth, formato errori, logging, versioning

Queste basi determinano la futura manutenibilità. Concordate presto standard per autenticazione/autorizzazione, un formato di errore coerente, correlazione delle richieste, versioning API e telemetria. Questo riduce attriti tra team portale, backend e operation.

3) Consegnare la prima tratta di portale end-to-end

Scegliete un processo con confini chiari (es. area documenti o consultazione stato). Importante è che tutta la catena sia presente: login, controllo dei diritti, API, UI, logging, monitoring, esercizio. Così l’organizzazione capisce rapidamente quali standard funzionano nella pratica.

4) Collegare il desktop in modo mirato: percorsi critici di scrittura via servizi

Quando i servizi sono stabili, migrate funzioni desktop selezionate: in particolare cambi di stato, approvazioni o validazioni centrali. Il desktop resta performante, ma le regole diventano più coerenti e l’accesso diretto al DB viene gradualmente ridotto.

5) Consolidare: eliminare regole duplicate e vie particolari

Col tempo altrimenti emergono «due sistemi». Pianificate consolidamenti regolari: quali regole esistono duplicate? Dove il portale può usare il servizio desktop? Quali report dovrebbero essere prodotti centralmente? L’obiettivo è una piattaforma gestibile, non un dogma.

Trappole tipiche dal punto di vista operativo – e come evitarle

Le regole vengono ricostruite nel portale

Questo porta a discrepanze e casi di supporto. Contromisura: Use-Case-API con validazioni lato server, ritorni di errore chiari e, se possibile, scenari di test funzionali condivisi.

Sovranità dei dati poco chiara tra desktop e portale

Se entrambi i client possono modificare „tutto“ nascono conflitti. Contromisura: modello di stati, responsabilità definite e concorrenza ottimistica per modifiche concorrenti.

La sicurezza è trattata come aggiunta successiva

Soprattutto nel portale clienti SSO, controlli tenant, download sicuri di file e audit sono necessari fin dall’inizio. Implementarli dopo è più costoso e aumenta il rischio di vulnerabilità.

Mancanza di trasparenza nell’esercizio

Senza Request-ID, log strutturati e health-check la diagnostica diventa lavoro da detective. Contromisura: observability come requisito obbligatorio delle prime release di servizio.

Conclusione: un nucleo di servizi collega la forza del desktop alla portata del portale

La combinazione di Delphi-desktop e portale web è per molte aziende la via più realistica per preservare processi core e contemporaneamente abilitare la collaborazione esterna. Cruciale è non gestire due mondi separati, ma creare un nucleo di servizi che unisca: Use-Case-API, diritti chiari, stati tracciabili, vie dati controllate e un modello operativo con logging, monitoring e deployment pianificabili.

Così si ottiene una modernizzazione con obiettivi intermedi: il desktop resta produttivo, il portale fornisce benefici precoci e l’architettura diventa passo dopo passo più coerente e manutenibile.

Nell’ambito funzionale giocano inoltre un ruolo le Delphi Modernisierung, quando integrazioni, flussi dati e sviluppo devono lavorare in armonia.

Discutere un progetto o un piano di modernizzazione con Net-Base.