Combinar Delphi Desktop y portales web: arquitectura, interfaces y modernización sin ruptura

En muchas empresas, la „central de control“ funcional ha crecido durante años como una aplicación de escritorio Delphi: cliente VCL, conocimiento profundo de procesos, captura de datos rápida, canales de impresión e informes, hardware especializado y con frecuencia un acceso directo a la base de datos en la LAN. Al mismo tiempo aumentan las expectativas sobre autoservicio y colaboración externa: los clientes quieren consultar el estado de pedidos, intercambiar documentos o registrar reclamaciones —sin VPN, sin despliegue masivo de clientes y sin instalaciones locales.

Combinar Delphi Desktop y portales web significa en la práctica unir ambos mundos de modo que la operación, la seguridad y la consistencia de los datos sigan siendo gestionables. No se trata de „reconstruir“ formularios en el navegador, sino de una arquitectura que separe con claridad procesos, permisos y rutas de datos, y que permita a ambos frontends operar bajo reglas comunes. El beneficio es una vía de modernización sin Big-Bang: el escritorio sigue siendo productivo mientras el portal web crece de forma controlada.

Este artículo está dirigido a la dirección de TI, administradores y responsables técnicos de proyecto. El foco está en los efectos sobre operación, administración, interfaces, seguridad, almacenamiento de datos y migración —menos en detalles de frameworks. Recibirá patrones prácticos, criterios de decisión y trampas típicas con sus contramedidas.

Por qué „Portal en lugar de Desktop“ rara vez es realista

En entornos B2B hay muchas razones por las que un cliente de escritorio sigue siendo sensato. Los administradores lo experimentan de forma concreta: un portal es ideal para usuarios distribuidos, pero ciertas tareas siguen siendo más eficientes o solo factibles desde el escritorio.

Fortalezas del escritorio que importan en el día a día

• Captura de datos compleja con formularios muy densos, manejo por teclado, vistas tabulares amplias y cambios rápidos entre registros.
• Periferia e integraciones locales como impresoras de etiquetas, escáneres, dispositivos seriales o componentes Windows especializados.
• Rendimiento cercano a la LAN, cuando se procesan grandes volúmenes de datos o un proceso requiere latencias extremadamente bajas.
• Flujos de trabajo consolidados con muchos casos especiales, donde un port 1:1 en un portal inicialmente plantea riesgos elevados.

Fortalezas del portal que cubren nuevas demandas

• Acceso externo para clientes, proveedores o socios, sin que sea necesario desplegar un cliente.
• Control central (versiones, funcionalidades, permisos) con un perímetro exterior claro.
• Independencia de dispositivo (navegador, uso móvil) para fuerza de ventas y dirección.
• Aperturas de proceso concretas como consultas de estado, cargas, aprobaciones o flujos de ticketing.

La utilidad está en la combinación: el escritorio permanece como herramienta de potencia para roles internos, y el portal se convierte en el acceso controlado para grupos de usuarios externos. Para evitar que esto derive en dos „verdades“ paralelas, se necesita un núcleo conector.

Si combina Delphi Desktop y portales web: tres arquitecturas objetivo

La decisión de arquitectura trata sobre todo de responsabilidades: ¿dónde reside la regla de negocio? ¿Quién puede modificar datos? ¿Qué capa es la „Single Source of Truth“ (es decir, la fuente autorizada para reglas y estados)? Para decisores técnicos es importante: la elección tiene consecuencias directas en operación, búsqueda de errores, gestión de releases y seguridad.

Variante A: Portal como complemento vía REST-API, el escritorio sigue siendo dominante

El portal cubre casos de uso seleccionados, típicamente „leer e iniciar acciones“: estados, documentos, aprobaciones, entradas sencillas. Para ello se introduce una Delphi REST-API o un REST-Server separado. La aplicación de escritorio puede continuar inicialmente accediendo directamente a la base de datos.

Ventaja operativa: inicio rápido, intervenciones mínimas en el escritorio, adecuado para un primer valor añadido del portal.

Punto de riesgo: existen dos rutas de datos (Escritorio → DB directo, Portal → API). Si las reglas de negocio residen solo en el escritorio, surgen inconsistencias. Como contramedida, las funciones del portal deberían comenzar deliberadamente en áreas donde las reglas son sencillas y representables en el servidor (p. ej. provisión de documentos, consulta de estado, acciones de aprobación definidas).

Variante B: Núcleo de servicios como capa de proceso común (recomendado en funcionamiento en paralelo)

Aquí desplaza progresivamente la lógica de negocio desde el escritorio hacia los servicios. Escritorio y portal usan los mismos endpoints. El escritorio se orienta más a Rich Client (UI, integraciones locales), mientras que las reglas y validaciones residen en el servidor.

Ventaja operativa: un punto central para permisos, auditoría, lógica de estado y validaciones; comportamiento consistente en todos los frontends.

Esfuerzo: mayor al inicio, porque hay que planear estándares de API, formatos de error, versionado, monitoreo y despliegue de forma ordenada. A cambio, el esfuerzo posterior disminuye notablemente al existir menos caminos especiales.

Variante C: El portal manda, el escritorio permanece como cliente especializado

Esta variante tiene sentido cuando el navegador debe convertirse estratégicamente en el acceso estándar (p. ej. organizaciones fuertemente distribuidas), y el escritorio sigue existiendo para roles que requieren hardware especializado o captura de alto rendimiento. El núcleo de servicios debe ser especialmente estable y escalable.

Arquitectura Layer-3 como guía comprensible

Independientemente de la variante, ayuda una Layer-3 Architektur: (1) presentación (Escritorio/Portal), (2) capa de aplicación y dominio (casos de uso, reglas), (3) infraestructura (base de datos, almacenamiento de archivos, mensajería, sistemas externos). Para los administradores esto es importante porque aclara los límites operativos: ¿qué es un „problema de frontend“, qué es un „problema de servicio“, qué corresponde a la base de datos o al storage? Esta separación acorta la búsqueda de errores y reduce efectos colaterales en los despliegues.

El vínculo práctico: cómo comparten escritorio y portal el mismo proceso

El mayor desafío rara vez es „construir el portal“, sino la cuestión: ¿cómo comparten escritorio y portal responsabilidades dentro del mismo proceso sin duplicar reglas? Tres patrones son especialmente relevantes en la práctica.

1) APIs orientadas a casos de uso en lugar de APIs de tablas o CRUD

Un punto muerto común es una API que únicamente expone tablas de la base de datos („Create/Read/Update/Delete“). Entonces las reglas deben recrearse en el portal y el escritorio mantiene sus propias reglas. Son preferibles las APIs orientadas a casos de uso: los endpoints describen acciones funcionales como „crear reclamación“, „liberar pedido“, „subir documento“, „confirmar estado de entrega“.

El efecto en operación es palpable: las validaciones se realizan en el servidor, los mensajes de error son reproducibles y ambos clientes (escritorio y portal) desencadenan el mismo flujo mediante la misma lógica.

2) Hacer manejables conflictos y reintentos

Con un portal aumenta la probabilidad de cambios paralelos y solicitudes repetidas (p. ej. por timeouts, reintentos o doble clic del usuario). Aquí ayudan tres conceptos sin recurrir a „bloqueos permanentes“:

• Idempotencia: las acciones críticas están diseñadas de modo que una repetición produce el mismo efecto y no provoca duplicados. En la práctica suele implementarse mediante un identificador único de la petición (Idempotency Key).
• Concurrencia optimista: un registro incluye información de versión (p. ej. información de versión de fila). Al modificar, el servicio verifica si la versión sigue siendo válida y devuelve conflictos de forma clara.
• Transacciones cortas: en lugar de „bloquearlo todo“, las operaciones de escritura se mantienen breves. Trabajos largos (p. ej. exportes, paquetes de informes) se ejecutan de forma asíncrona.

Para los decisores técnicos es importante: estos mecanismos reducen el esfuerzo de soporte porque los escenarios de error („ocurrió dos veces“, „mi cambio desapareció“) se vuelven mucho menos frecuentes.

3) Modelar estados y transiciones con claridad

Si el escritorio maneja casos complejos y el portal „solo“ crea solicitudes o pre-etapas, necesita transiciones de estado definidas. Un recorte práctico es: el portal crea o complementa procesos dentro de rangos de estado claramente acotados (p. ej. „presentado“), el escritorio procesa los casos especiales, y el núcleo de servicios decide y registra los cambios de estado. Así se evita que el cliente del portal pueda, de forma indirecta, „configurar mal“ procesos.

Datos y documentos: el área de integración que con frecuencia se subestima

Casi todo portal introduce operaciones con archivos: cargas, comprobantes, albaranes, imágenes, salidas en PDF. Para los administradores este es un punto central porque afecta backups, permisos, escaneo antivirus, costes de almacenamiento y rendimiento.

¿Dónde almacenar archivos: base de datos, fileshare u objeto storage?

Hay tres opciones habituales de almacenamiento, cada una conduciendo a una realidad operativa distinta:

• Base de datos (BLOB): adecuada cuando las transacciones deben estar estrictamente acopladas y el backup/restore debe permanecer en un único paquete. Las desventajas suelen ser bases de datos de mayor tamaño y ventanas de backup más largas.
• Sistema de archivos/Share: típico On-Prem, bien integrable en conceptos de respaldo existentes. Es importante contar con permisos claros y una capa API que controle el acceso.
• Object-Storage: apropiado para escalado, reglas de ciclo de vida o cuando los accesos externos deben encapsularse técnicamente. Requiere un modelo consciente de claves y permisos.

Independientemente del lugar de almacenamiento: el portal no debería descargar archivos „directamente“ desde un share. Es preferible un download controlado a través de endpoints de servicio con verificación de permisos, registro y, opcionalmente, URL de descarga con caducidad temporal.

PDFs e informes: en el servidor en lugar de duplicarlos

Las aplicaciones de escritorio Delphi a menudo tienen canales de impresión e informes consolidados. Los portales suelen necesitar los mismos contenidos en PDF. En vez de mantener dos implementaciones, merece la pena una generación central de documentos en el núcleo de servicios: plantillas, versionado y formatos de salida en el servidor; tanto el escritorio como el portal consumen el resultado. Para la operación esto aporta ventajas claras: salidas trazables, almacenamiento homogéneo y menor dependencia de instalaciones de escritorio.

REST-Server y servicios: Delphi, C# o una arquitectura mixta

En la decisión „Delphi o C#“ importa menos la ideología que la capacidad del equipo, el entorno operativo y la mantenibilidad. En muchos entornos una arquitectura mixta es realista, siempre que las responsabilidades estén bien delimitadas.

Delphi como plataforma de servicios: sensata cuando la lógica de negocio ya existe allí

Si la lógica de negocio y el acceso a datos ya están sólidamente implementados en Delphi, un REST-Server basado en Delphi puede ser eficiente. Para administradores y decisores es importante comprender: operar un servidor no es „mantener el escritorio ejecutándose“. Un servicio productivo necesita configuración clara, timeouts bien definidos, logs estructurados, health checks y un despliegue reproducible.

Tambi én la conexión a datos debería modernizarse si todavía se usan drivers antiguos o la BDE está en juego. Una BDE-Ablösung y la migración a accesos de datos modernos reducen las incidencias en producción y facilitan el despliegue al requerir menos componentes legacy instalados y mantenidos.

Servicios C# en el ecosistema de portal: frecuente por hosting e identidad

Si el portal se desarrolla en un paisaje dominado por .NET, los C# Services suelen ser una opción lógica —no menos por la integración de identidad, estándares operativos existentes y el hosting detrás de Microsoft IIS o en plataformas contenerizadas. Es crucial evitar doble implementación: o bien la lógica de negocio central permanece en servicios Delphi y C# se encarga de temas de borde (p. ej. orquestación específica del portal), o planifican conscientemente una migración de lógica a .NET —pero entonces de forma controlada y con límites de dominio claros.

API-Gateway: elemento de orden, pero no obligatorio

Un API-Gateway puede centralizar funciones (enrutamiento, rate-limits, logging, autenticación). Para arquitecturas de inicio pequeñas a menudo basta con una API consistente y estándares unificados. En cuanto existen varios servicios y grupos de usuarios, un gateway ayuda a mantener estable la fachada exterior y a aplicar políticas de forma central.

Autenticación y permisos: del escritorio interno al mundo exterior del portal

Con un portal cambia el panorama de usuarios: además de usuarios internos aparecen cuentas externas, roles y tenants. De ello derivan requisitos sobre identidad, permisos y auditabilidad. Para los administradores es relevante porque los sistemas de identidad y los modelos de roles suelen ser costosos de cambiar después.

SSO con SAML 2.0 u OIDC: menos trabajo admin, mejor control

En setups B2B es habitual SAML 2.0 (Single Sign-on mediante un Identity Provider), porque las empresas quieren reutilizar identidades existentes. OIDC (OpenID Connect) también es común, sobre todo en plataformas más modernas. Los inicios clásicos con usuario/contraseña son posibles, pero conllevan trabajo adicional para política de contraseñas, MFA, procesos de reseteo y soporte.

Importante para la arquitectura: la autenticación (¿quién eres?) y la autorización (¿qué puedes hacer?) deben validarse en el servidor —no en el frontend del portal.

Soporte multiinquilino y modelo de roles: no lo añada „después“

Un portal de clientes requiere casi siempre separación por tenant: un cliente solo ve sus datos. Esto debe representarse en el núcleo de servicios, idealmente mediante:

• Claims en el token (p. ej. Tenant-ID, roles, referencia contractual), para que los servicios puedan tomar decisiones.
• Comprobaciones a nivel de registro (Row-Level-Checks en la lógica de negocio), no solo „ocultar menús“.
• Trails de auditoría para acciones importantes (quién, qué, cuándo), además de correlación mediante una Request-ID para analizar errores.

El escritorio también puede —si se desea— usar tokens contra el mismo stack de identidad. Esto reduce caminos especiales y facilita la trazabilidad de cambios, especialmente cuando portal y escritorio modifican el mismo registro.

Modernizar el acceso a datos: FireDAC, PostgreSQL y rutas de datos controladas

Muchas soluciones de escritorio Delphi crecieron históricamente con acceso directo a la BD. Tan pronto como se añade un portal, eso se convierte en un tema de arquitectura: las rutas de datos deben ser controlables, las validaciones deben aplicarse de forma central y el rendimiento ha de mantenerse estable incluso bajo carga paralela.

FireDAC como base para un acceso a datos mantenible

La BDE-Ablösung con conexión nativa es un estándar extendido en entornos Delphi para el acceso a bases de datos modernas. Lo importante no es tanto el componente en sí como la unificación: consultas parametrizadas, límites transaccionales limpios, manejo de errores consistente y tiempos de ejecución medibles. Para la operación cuenta que los timeouts y el consumo de recursos sean previsibles y que los problemas puedan rastrearse en logs y en el monitoring.

PostgreSQL con Delphi: manejable con un buen concepto de tipos y migraciones

PostgreSQL con Delphi es robusto si el mapeo de tipos (p. ej. UUID, timestamps, campos JSON), los índices y las migraciones de esquema se gestionan de forma ordenada. Los portales generan muchas consultas filtradas para listas; por ello filtros, paginación y ordenación deben implementarse en el servidor para evitar transferir volúmenes innecesarios. Esto reduce carga y mejora la experiencia de usuario sin penalizar al escritorio.

Operación, despliegue y monitoreo: dotar de madurez portal a backends Delphi

Un portal suele estar permanentemente disponible y por tanto es más exigente en operación que una sola aplicación de escritorio. Para los administradores este es el ámbito donde una buena arquitectura rinde inmediatamente: despliegues trazables, observabilidad clara (logs/métricas) y ventanas de mantenimiento definidas.

Servicio Windows o servicio Linux: lo decisivo es el modelo operativo

Un servicio Delphi puede ejecutarse como Windows- y Linux-Services o como daemon Linux. Más importante que el sistema operativo son los estándares que estabilizan la operación:

• Health-Checks para monitoring y load balancer (p. ej. „servicio vivo“ y „base de datos accesible“).
• Logging estructurado (incl. Request-ID, usuario/tenant, tiempos de ejecución, códigos de estado), para que los casos de soporte sean reproducibles.
• Configuración sin rebuild (p. ej. variables de entorno, ficheros de configuración central), para que los despliegues puedan automatizarse limpiamente.
• Capacidad de rollback mediante versiones claras y cambios de base de datos seguros para migraciones.

Perfiles de carga: el portal son „muchas requests cortas“ en lugar de „pocas sesiones largas“

El uso de escritorio suele generar fases de trabajo más largas por usuario, mientras que los portales provocan muchas solicitudes cortas y paralelas. Medidas técnicas típicas son:

• paginación consecuente, filtros en el servidor y respuestas con tamaños limitados
• caching para datos maestros y consultas poco cambiantes
• trabajos asíncronos para tareas largas (exportes, paquetes de informes)
• rate-limits y mecanismos de protección contra uso abusivo

Para los decisores es central: el rendimiento no es un „ajuste fino al final“, sino parte de la definición de la API (tamaños de respuesta, timeouts, procesamiento en background).

Modernización sin Big-Bang: una vía robusta en cinco pasos

Un nuevo desarrollo completo rara vez es necesario y con frecuencia es arriesgado porque el conocimiento de proceso reside en el cliente Delphi. Se ha mostrado eficaz un enfoque en el que cada etapa es utilizable en producción y no pone en peligro la operación.

1) Inventario: procesos, soberanía de datos, integraciones

No empiece por las pantallas, empiece por los casos de uso: ¿qué flujos deben ir al portal? ¿Qué datos puede ver o modificar un usuario externo? ¿Qué interfaces existen con ERP, DMS o CRM? De ahí surge una lista priorizada de APIs que aportan valor real.

2) Definir básicos de servicio: auth, formato de error, logging, versionado

Esta base decide la mantenibilidad posterior. Acorde pronto estándares para autenticación/autorizar, un formato de error consistente, correlación de peticiones, versionado de API y telemetría. Esto reduce fricciones entre equipo de portal, equipo de backend y operación.

3) Entregar la primera ruta del portal end-to-end

Elija un proceso con una delimitación clara (p. ej. área de documentos o consulta de estado). Es importante que la cadena completa funcione: login, verificación de permisos, API, UI, logging, monitoring, operación. Así la organización detecta pronto qué estándares funcionan en la práctica.

4) Conectar el escritorio de forma selectiva: rutas de escritura críticas vía servicios

Una vez que los servicios son estables, traslade funciones seleccionadas del escritorio: especialmente cambios de estado, aprobaciones o validaciones centrales. El escritorio sigue siendo eficaz, pero las reglas son más coherentes y el acceso directo de escritura a la BD se reduce gradualmente.

5) Consolidar: eliminar reglas duplicadas y caminos especiales

Con el tiempo, de lo contrario surgen „dos sistemas“. Planifique consolidaciones periódicas: ¿qué reglas existen duplicadas? ¿Dónde puede el portal usar el servicio del escritorio? ¿Qué informes deben generarse centralmente? El objetivo es una plataforma gobernable, no un dogma.

Trampas típicas desde la perspectiva operativa —y cómo evitarlas

Las reglas se reimplementan en el portal

Esto conduce a desviaciones y casos de soporte. Contramedida: APIs orientadas a casos de uso con validaciones server-side, devoluciones de error claras y, cuando sea posible, escenarios de prueba funcionales compartidos.

Indefinida soberanía de datos entre escritorio y portal

Si ambos clientes pueden modificar „todo“, surgen conflictos. Contramedida: modelo de estados, responsabilidades definidas y concurrencia optimista para cambios concurrentes.

La seguridad se trata como un añadido posterior

Especialmente en el portal de clientes, SSO, comprobaciones por tenant, descargas seguras de archivos y auditoría son necesarios desde el inicio. Añadirlos después es más caro y aumenta el riesgo de brechas.

Falta de transparencia en la operación

Sin Request-IDs, logs estructurados y health-checks la búsqueda de errores se convierte en trabajo detectivesco. Contramedida: observabilidad como requisito en las primeras releases de servicio.

Conclusión: un núcleo de servicios une la potencia del escritorio con el alcance del portal

La combinación de Delphi-Desktop y portal web es en muchas empresas la vía más realista para conservar procesos centrales existentes y a la vez permitir colaboración externa. Lo decisivo es no operar dos mundos separados, sino crear un núcleo de servicios conector: APIs orientadas a casos de uso, permisos claros, estados trazables, rutas de datos controladas y un modelo operativo con logging, monitoring y despliegues planificables.

Así se produce una modernización con objetivos intermedios: el escritorio sigue siendo productivo, el portal aporta valor temprano y la arquitectura se vuelve progresivamente más coherente y mantenible.

En el entorno funcional también juegan un papel importante la Delphi Modernisierung, cuando integraciones, flujos de datos y evolución deben operar de forma coordinada.

Discutir proyecto o iniciativa de modernización con Net-Base.