Combinar Delphi Desktop i portals web: arquitectura, interfícies i modernització sense trencament

En moltes empreses la «central d’operacions» funcional ha crescut durant anys com una aplicació d’escriptori Delphi-Desktop: VCL-Client, coneixement profund dels processos, captura ràpida de dades, rutes d’impressió i reporting, maquinari especialitzat i sovint accés directe a la base de dades a la LAN. Al mateix temps augmenten les expectatives de self-service i col·laboració externa: els clients volen comprovar l’estat de comandes, intercanviar documents o registrar reclamacions —sense VPN, sense desplegament d’escriptoris i sense instal·lacions locals.

Combinar Delphi Desktop i portals web vol dir en la pràctica integrar aquests dos mons de manera que l’operació, la seguretat i la consistència de les dades siguin gestionables. No és determinant «recrear» pantalles al navegador, sinó dissenyar una arquitectura que separi netament processos, drets i rutes de dades i permeti que ambdós frontends operin segons regles comunes. El resultat és un camí de modernització sense Big-Bang: el desktop continua sent productiu mentre el portal web creix de manera controlada.

Aquest article està dirigit a la direcció TI, administradors i responsables tècnics de projecte. El focus està en les repercussions sobre operacions, administració, interfícies, seguretat, emmagatzematge de dades i migració —menys detalls de frameworks. Rebreu patrons pràctics, criteris de decisió i trampes típiques amb les seves contramesures.

Per què «Portal en lloc de Desktop» rarament és realista

En entorns B2B hi ha moltes raons per les quals un client d’escriptori continua tenint sentit. Els administradors ho perceben sovint de manera concreta: un portal és ideal per usuaris distribuïts, però certes tasques continuen sent més eficients o només possibles des del desktop.

Punts forts del desktop que compten en el dia a dia

• Captura de dades complexa amb pantalles d’alta densitat, ús intensiu del teclat, vistes tabulars grans i canvis ràpids entre registres.
• Perifèrics i integracions locals com impressores d’etiquetes, escàners, dispositius sèrie o components Windows específics.
• Rendiment proper a la LAN quan es processa gran volum de dades o quan un procés exigeix latències molt baixes.
• Fluxos de treball consolidats amb molts casos especials, on un port 1:1 en un portal comporta riscos elevats a curt termini.

Punts forts del portal que cobreixen noves necessitats

• Accés extern per a clients, proveïdors o socis, sense necessitat de desplegar un client.
• Control central (versions, funcionalitats, permisos) amb una vora exterior clara.
• Independència de dispositiu (navegador, ús mòbil) per a personal de camp i direcció.
• Apertures de procés concretes com consultes d’estat, uploads, aprovacions o gestió de tiquets.

La utilitat està en la combinació: el desktop roman com l’eina potent per a rols interns i el portal es converteix en l’accés controlat per a grups d’usuaris externs. Per evitar que això es converteixi en dues «veritats» paral·leles cal un nucli que les uneixi.

Quan combineu Delphi Desktop i portals web: tres arquitectures objectiu

La decisió arquitectònica tracta sobretot de responsabilitats: on resideix la regla de negoci? Qui pot modificar dades? Quina capa és la «Single Source of Truth» (la font autoritària per a regles i estats)? Per a decisors tècnics és important: l’elecció té efectes directes en operacions, cerca d’errors, gestió de llançaments i seguretat.

Variante A: portal com a complement via REST-API, el desktop continua dominant

El portal cobreix casos d’ús seleccionats, típicament «llegir i desencadenar»: estats, documents, aprovacions, captures simples. Per això s’introdueix una Delphi REST-API o un REST-server separat. L’aplicació d’escriptori pot continuar accedint inicialment a la base de dades de forma directa.

Avantatge operatiu: arrencada ràpida, pocs canvis al desktop, idoni per obtenir un primer valor amb el portal.

Punt de risc: existeixen dues rutes de dades (Desktop → DB directe, Portal → API). Si les regles de negoci resideixen només al desktop es generen incoherències. Com a contramesura, les funcionalitats del portal han d’iniciar-se conscientment on les regles siguin senzilles i es puguin reflectir al servidor (p. ex. disponibilitat de documents, consulta d’estat, accions d’aprovació definides).

Variante B: nucli de serveis com a capa de procés comuna (recomanat per a funcionament en paral·lel)

Aquí traslladeu de forma incremental la lògica de negoci fora del desktop cap a serveis. Desktop i portal utilitzen els mateixos endpoints. El desktop es converteix més en Rich Client (IU, integracions locals) i les regles i validacions s’executen al servidor.

Avantatge operatiu: un punt central per a permisos, audit, lògica d’estat i validacions; comportament coherent a tots els frontends.

Esforç: més elevat a l’inici, perquè cal planificar estàndards d’API, formats d’errors, versionat, monitoratge i desplegament. A canvi, l’esforç disminueix clarament més endavant perquè hi ha menys camins especials.

Variante C: el portal lidera, el desktop queda com a client especial

Aquesta variant té sentit si el navegador ha de ser l’accés estàndard per estratègia (p. ex. organització altament distribuïda), però el desktop es manté per a rols amb maquinari especial o captura d’alt rendiment. El nucli de serveis ha de ser especialment estable i escalable per a aquesta opció.

Layer-3 arquitectura com a guia comprensible

Independently de la variant, una Layer-3 Architektur ajuda: (1) presentació (Desktop/Portal), (2) capa d’aplicació i domini (casos d’ús, regles), (3) infraestructura (base de dades, emmagatzematge de fitxers, messaging, sistemes externs). Per als administradors això és important perquè les fronteres operatives queden clares: què és «problema de frontend», què és «problema de servei», què depèn de la base de dades o l’emmagatzematge? Aquesta separació redueix el temps de cerca d’errors i minimitza efectes secundaris en deploys.

Relació pràctica: com comparteixen procés desktop i portal

El principal repte rarament és «construir el portal», sinó respondre: com reparteixen desktop i portal responsabilitats dins del mateix procés sense duplicar regles? Tres patrons són especialment rellevants en la pràctica.

1) APIs per cas d’ús en lloc d’APIs de taules o CRUD

Un carreró sense sortida habitual és una API que només exposa taules de base de dades («Create/Read/Update/Delete»). Llavors cal reproduir regles al portal i el desktop manté les seves pròpies regles. És preferible APIs per cas d’ús: endpoints que descriuen accions funcionals com «crear reclamació», «aprovar comanda», «pujar document», «confirmar estat d’entrega».

L’efecte operatiu és notable: les validacions s’executen al servidor, els errors són reproduïbles i ambdós clients (desktop i portal) encadenen el mateix flux mitjançant la mateixa lògica.

2) Fer manejables conflictes i repeticions

Amb un portal augmenta la probabilitat de modificacions paral·leles i de peticions repetides (p. ex. per timeouts, reintents o doble clic d’usuari). Ajuden tres conceptes sense introduir «bloquejos permanents»:

• Idempotència: les accions crítiques es dissenyen perquè una repetició produeixi el mateix efecte i no executi res doble. A la pràctica sovint s’implementa amb una clau única per la petició (Idempotency Key).
• Concurrència optimista: un registre porta informació de versió (p. ex. «Row Version»). En modificar-se, el servei comprova que la versió encara coincideix i comunica conflictes de forma clara.
• Transaccions curtes: en lloc de «bloquejar-ho tot», les operacions d’escriptura es mantenen breus. Tasques llargues (p. ex. exports, paquets d’informes) s’executen de forma asíncrona.

Per a decisors tècnics és rellevant: aquests mecanismes redueixen la càrrega de suport perquè apareixen molt menys incidències del tipus «s’ha produït dues vegades» o «el meu canvi ha desaparegut».

3) Modelar estats i transicions amb claredat

Si el desktop tracta casos complexos i el portal només registra sol·licituds o preetapes, calen transicions d’estat definides. Un tall pràctic és: el portal crea o completa processos en àrees d’estat clarament delimitades (p. ex. «presentat»), el desktop gestiona casos especials i el nucli de serveis determina i registra els canvis d’estat. Així s’evita que el client del portal pugui «configurar» processos de manera indirecta i errònia.

Dades i documents: l’àrea d’integració sovint infravalorada

Quasi qualsevol portal incorpora operacions amb fitxers: uploads, justificants, albarans, imatges, sortides PDF. Per als administradors això és un punt clau perquè afecta backup, permisos, escaneig antivirus, costos d’emmagatzematge i rendiment.

On s’emmagatzemen els fitxers: base de dades, Fileshare o object storage?

Hi ha tres opcions habituals d’emmagatzematge, cadascuna amb una realitat operativa diferent:

• Base de dades (BLOB): útil quan les transaccions han d’estar estrictament acoblades i el backup/restore ha de ser un paquet únic. Els inconvenients són sovint bases de dades més grans i finestres de backup més llargues.
• Filesystem/Share: típic On-Prem, fàcil d’integrar en conceptes de backup existents. És important disposar de permisos clars i d’una capa d’API que controli l’accés.
• Object-Storage: adequat quan cal escalar, aplicar regles de cicle de vida o encapsular accés extern de manera tècnicament neta. Requereix un model conscient de claus i permisos.

Independentment de la ubicació, el portal no hauria de carregar fitxers «directament» d’un share. És preferible una descàrrega controlada a través d’endpoints de servei amb comprovació de permisos, registre (logging) i URL de descàrrega temporal opcional.

PDFs i informes: generació al servidor en lloc de duplicar

Les aplicacions d’escriptori Delphi sovint tenen rutes d’impressió i reporting evolucionades. Els portals sovint necessiten el mateix contingut en PDF. En lloc de mantenir dues implementacions, val la pena centralitzar la generació de documents al nucli de serveis: plantilles, versionat i formats de sortida al servidor; desktop i portal consumeixen el resultat. Per a l’operació això comporta avantatges clars: sortides rastrejables, emmagatzematge homogeni i menys dependències de instal·lacions d’escriptori.

REST-Server i serveis: Delphi, C# o arquitectura mixta

A l’hora de decidir «Delphi o C#» l’elecció per a les empreses sol dependre menys d’ideologia i més de l’equip, el model operatiu i la mantenibilitat. En molts entorns una arquitectura mixta és realista sempre que les responsabilitats estiguin ben delimitades.

Delphi com a plataforma de serveis: adequat si ja hi ha lògica de domini

Si la lògica de negoci i l’accés a dades ja estan ben assentats en Delphi, un REST-Server basat en Delphi pot ser eficient. Per a administradors i decisors és important: operar un servei no és «mantenir el desktop en execució permanent». Un servei productiu necessita una configuració clara, timeouts ben definits, logs estructurats, health-checks i un desplegament reproducible.

També cal modernitzar la connexió a dades si encara hi ha drivers antics o la BDE en joc. Una BDE-Ablösung i la migració a accessos de dades moderns redueixen incidències en producció i faciliten el desplegament, perquè calen i s’han de mantenir menys components legacy.

C# services dins l’ecosistema del portal: freqüent per hosting i identitat

Si el portal es desenvolupa en un paisatge dominat per .NET, els C# Services són una opció comuna —no només per la integració d’Identity, sinó per estàndards operatius existents i hosting darrere de Microsoft IIS o en plataformes containeritzades. El crucial és evitar doble implementació: o bé la lògica de negoci central roman en serveis Delphi i C# es fa càrrec d’assumptes d’edge (p. ex. orquestració específica del portal), o bé es planifica una migració controlada de lògica cap a .NET amb límits funcionals clars.

API-Gateway: element d’ordre, però no imprescindible

Un API-Gateway pot concentrar funcions centrals (routing, rate-limits, logging, autenticació). Per a arquitectures d’arrencada petites sovint n’hi ha prou amb una API consistent amb estàndards únics. Però quan existeixen diversos serveis i grups d’usuaris, un gateway ajuda a mantenir estable la vora exterior i a aplicar polítiques de manera centralitzada.

Autenticació i permisos: de l’escriptori intern a l’entorn extern del portal

Amb un portal canvia el panorama d’usuaris: a més d’usuaris interns apareixen comptes externs, rols i múltiples tenants. Això genera requisits sobre identity, permisos i auditabilitat. Per als administradors és rellevant perquè els sistemes d’identitat i els models de rols són difícils de modificar més endavant.

SSO amb SAML 2.0 o OIDC: menys feina d’admin, millor control

En setups B2B és habitual SAML 2.0 (single sign-on via un Identity Provider), perquè les empreses volen reutilitzar identitats existents. OIDC (OpenID Connect) també és comú, especialment en plataformes més modernes. Els logins clàssics amb usuari/contrasenya són possibles, però impliquen treball addicional per política de contrasenyes, MFA, processos de reset i suport.

Crucial per l’arquitectura: autenticació (qui ets?) i autorització (què pots fer?) han de ser verificades al servidor —no al frontend del portal.

Multi-tenant i model de rols: no afegiu-ho «més endavant»

Un portal de client requereix pràcticament sempre separació per tenant: un client només veu les seves dades. Això s’ha de representar al nucli de serveis, idealment mitjançant:

• Claims al token (p. ex. Tenant-ID, rols, referència contractual), perquè els serveis puguin prendre decisions.
• Comprovacions a nivell de registre (Row-Level-Checks) a la lògica de negoci, no només «amagar menus».
• Traçabilitat (Audit-Trails) per a accions rellevants (qui, què, quan), més correlació via Request-ID per a l’anàlisi d’errors.

El desktop també pot —si es vol— utilitzar tokens contra el mateix stack d’identitat. Això redueix camins especials i facilita la traçabilitat dels canvis, especialment quan portal i desktop editen el mateix registre.

Modernitzar l’accés a dades: FireDAC, PostgreSQL i rutes de dades controlades

Moltes solucions desktop Delphi han crescut amb accés directe a la BD. Quan s’afegeix un portal això es converteix en un tema arquitectònic: cal controlar les rutes de dades, fer que les validacions siguin centrals i assegurar que el rendiment es manté sota càrrega paral·lela.

FireDAC com a base per a un accés a dades sostenible

BDE-Ablösung mit nativer Anbindung és un estàndard difós en entorns Delphi per accedir a bases de dades modernes. Importa menys la component en si i més la unificació: consultes parametritzades, límits de transacció nets, maneig d’errors homogeni i temps d’execució mesurables. Per a l’operació compta que els timeouts i el consum de recursos siguin previsibles i que els incidents puguin rastrejar-se en logs i monitoratge.

PostgreSQL amb Delphi: ben controlable amb un concepte net de tipus i migracions

PostgreSQL amb Delphi és robust si el mapeig de tipus (p. ex. UUID, timestamps, camps JSON), els índexs i les migracions d’esquema es tracten de manera ordenada. Els portals generen moltes consultes amb filtres i llistats; per això cal implementar filtres, paginació i ordenació al servidor per evitar transferir grans volums de dades innecessàries. Això redueix càrrega i millora l’experiència d’usuari sense fer més lent el desktop.

Operació, desplegament i monitoratge: portar la maduresa del portal als backends Delphi

Un portal està generalment disponible de manera contínua i per això exigeix més operacions que un simple desktop. Per als administradors és l’àrea on una bona arquitectura es paga de seguida: desplegaments rastrejables, observability clara (logs/mètriques) i finestres de manteniment definides.

Windows-Service o Linux-Service: el model operatiu és el que compta

Un servei Delphi es pot operar com a Windows- i Linux-Services o com a daemon Linux. Més important que el sistema operatiu són els estàndards que estabilitzen l’operació:

• Health-Checks per a monitoratge i load balancer (p. ex. «servei viu» i «base de dades accessible»).
• Logging estructurat (incloent Request-ID, usuari/tenant, temps d’execució, codis d’estat) per fer reproduïbles els casos de suport.
• Configuració sense recompilar (p. ex. variables d’entorn, fitxers de configuració centrals) per automatitzar deploys ordenadament.
• Capacitat de rollback mitjançant versions clares i migracions de base de dades segures.

Perfils de càrrega: el portal són «moltes peticions curtes» en lloc de «poques sessions llargues»

L’ús de desktop sovint genera fases de treball llargues per usuari, mentre que els portals generen moltes peticions curtes i paral·leles. Mesures tècniques típiques són:

• paginació consistent, filtres al servidor i limitació de la mida de resposta
• cache per dades mestres i consultes poc freqüents
• feines asíncrones per tasques llargues (exports, paquets d’informes)
• rate-limits i mecanismes de protecció contra ús malintencionat

Per a decisors és central: el rendiment no és un «retoc al final», sinó part de la definició de l’API (mida de resposta, timeouts, processament en background).

Modernitzar sense Big-Bang: un camí robust en cinc passos

Un nou desenvolupament complet és rarament necessari i sovint arriscat perquè el coneixement de procés està incrustat al client Delphi. Ha demostrat ser eficaç un enfoc en què cada etapa és productiva i no posa en perill l’operació.

1) Inventari: processos, propietat de dades, integracions

No comenceu per pantalles, sinó per casos d’ús: quins fluxos han d’anar al portal? Quines dades pot veure o modificar un usuari extern? Quines interfícies existeixen amb ERP, DMS o CRM? Això genera una llista d’APIs prioritzada que aporta valor real.

2) Definir conceptes bàsics de servei: Auth, format d’errors, logging, versionat

Aquesta base determina la futura mantenibilitat. Convenir aviat estàndards per autenticació/autorizació, un format d’errors consistent, correlació de peticions, versionat d’API i telemetria redueix friccions entre l’equip del portal, el backend i operacions.

3) lliurar la primera traça del portal de punta a punta

Trieu un procés amb delimitació clara (p. ex. àrea de documents o consulta d’estat). És important que la cadena completa estigui operativa: login, comprovació de permisos, API, IU, logging, monitoratge i operació. Així l’organització detecta aviat quins estàndards funcionen en producció.

4) connectar el desktop de manera selectiva: camins d’escriptura crítics via serveis

Quan els serveis són estables, migreu funcionalitats des del desktop: especialment canvis d’estat, aprovacions o validacions centrals. El desktop es manté potent, però les regles es tornen més coherents i l’accés directe d’escriptori a la BD es redueix pas a pas.

5) Consolidar: eliminar regles dobles i camins especials

Si no es fa, acabarà existint «dos sistemes». Planifiqueu consolidacions periòdiques: quines regles estan duplicades? On pot el portal reutilitzar serveis del desktop? Quins informes han de generar-se centralment? L’objectiu és una plataforma gestionable, no un dogma.

Trampes típiques des de la perspectiva operativa — i com evitar-les

Les regles es reimplementen al portal

Això genera desviacions i incidències de suport. Contramesura: APIs per cas d’ús amb validacions servidor-side, retorns d’errors clars i, si és possible, escenaris de proves funcionals compartits.

Propietat de dades poc clara entre desktop i portal

Si ambdós clients poden modificar «tot», apareixen conflictes. Contramesura: model d’estats, responsabilitats definides i concurrència optimista per a canvis concurrents.

La seguretat es tracta com un afegit posterior

En els portals de client, SSO, comprovacions de tenant, descàrregues segures i audit han de ser considerats des del principi. Fer-ho després és més car i augmenta el risc de bretxes de seguretat.

Falta de transparència en l’operació

Sense Request-IDs, logs estructurats i health-checks la cerca d’errors es converteix en feina de detectiu. Contramesura: l’observabilitat és obligatòria en les primeres versions dels serveis.

Conclusió: un nucli de serveis uneix la potència del desktop amb l’abast del portal

La combinació d’un desktop Delphi i un portal web és el camí més realista per a moltes empreses per mantenir processos nuclears i alhora permetre col·laboració externa. El que compta és no operar dues realitats separades, sinó crear un nucli de serveis que les connecti: APIs per cas d’ús, permisos nets, estats rastrejables, rutes de dades controlades i un model operatiu amb logging, monitoratge i desplegaments planificables.

Així s’aconsegueix una modernització amb objectius intermèdics: el desktop continua sent productiu, el portal aporta valor aviat i l’arquitectura es torna pas a pas més consistent i mantenible.

En l’àmbit funcional també tenen un paper important les Delphi Modernisierung, quan integracions, fluxos de dades i evolució han de treballar conjuntament de manera neta.

Parli d’un projecte o d’una iniciativa de modernització amb Net-Base.