La aplicación es el modelo · On-premise · Open source próximamente
Tu empresa lleva veinte años evolucionando.
Su software, tres reescrituras.
Cada tecnología que sostuvo tu aplicación se sustituyó entera, y con ella se fue la definición de cómo trabajas. En e-cometa las pantallas y los procesos de negocio no son código: son metadatos junto a tus datos, que se editan en producción y siguen ahí cuando cambia el motor que los interpreta.
Toda la tecnología que hemos puesto en producción ha caducado.
El conocimiento del negocio, nunca.
tú → Claude · MCP e-cometa "en el formulario de artículos añade un campo caducidad y hazlo visible" Claude ✓ add_field · CR-Fields fieldName: caducidad dataType: DatePicker visible: S ✓ el usuario ya ve el campo nuevo ✓ 0 recompilaciones · 0 redespliegues
0
redespliegues para cambiar una pantalla
1 JAR
aloja N aplicaciones aisladas, multi-tenant
<1 sem
hasta la primera aplicación sobre tu base de datos
100%
desplegable on-premise · open source, próximamente
Turning Vaadin into a Dynamic Enterprise Platform Through Metadata
César Quinteiro Rendo (Intergal) presenta el modelo que hay detrás de e-cometa: metadatos en lugar de código, procesos de negocio declarados, multi-tenant y escalado en Kubernetes, con las cifras de un ERP en producción.
15:15 CEST · Main Track
El problema de fondo
¿Dónde vive hoy el conocimiento de tu negocio?
En ocho sitios a la vez, cada uno con su formato y su dueño. Ninguna versión, ninguna auditoría, y nadie capaz de decir qué cambió, cuándo y por qué.
if (rol.equals("SUPERVISOR")) descuentoMax = 15;
Código de interfaz
@PostMapping("/pedidos") validarLimiteCredito(cliente);
Servicios de backend
CONSTRAINT ck_dto CHECK (descuento <= 15)
Restricciones de la base de datos
PROCEDURE recalcular_tarifas( p_quincena IN NUMBER)
Procedimientos almacenados
facturacion.dia_corte=15 facturacion.reintentos=3
Ficheros de configuración
SUPERVISOR │ pedido │ UPD │ S COMERCIAL │ pedido │ UPD │ N
Tablas de permisos
H24 Dto. especial 15 % H25 ¿sigue vigente?
Una hoja de cálculo
«Antes de facturar, revisar
los albaranes del día 15»Una página de wiki de 2019
Y en la cabeza de la persona que lleva doce años aquí, que no está documentada en ninguna parte y algún día se jubila.
El conocimiento atrapado en código muere con la pila que lo sostiene. El que está declarado en un modelo migra hacia delante.
Cincuenta años dibujando formularios: primero en código, luego arrastrando componentes en un editor visual. El artefacto "pantalla" sigue ahí, separado de los datos, desincronizándose con cada cambio de esquema y exigiendo un redespliegue por retoque.
e-cometa elimina el artefacto. No hay pantallas guardadas en ningún sitio: hay metadatos junto a tus datos, y un motor que los interpreta en cada carga. La interfaz siempre refleja la base de datos porque deriva de ella. Eso no es una mejora incremental sobre dibujar pantallas — es dejar de dibujarlas.
Y no, no es un fichero de configuración con esteroides: la configuración ajusta una aplicación, el metadato es la aplicación. Legible por personas, ejecutable por máquinas, independiente de la tecnología que hoy lo interpreta, y en un único sitio.
El código se reescribe. Los metadatos se adaptan.
No sólo pantallas
Los procesos de negocio también son metadatos
Una aplicación de gestión no se limita a consultar y editar registros: confirma pedidos, recalcula totales, genera el XML para la Administración, emite informes, imprime etiquetas o manda correos. En e-cometa todo eso es un proceso: una secuencia de pasos definida en metadatos, no programada.
El flujo se bifurca según el resultado de cada paso, se detiene a pedir una decisión al usuario y continúa donde lo dejó. Un proceso se lanza desde un botón del listado o del formulario, al guardar un registro, al terminar un informe o desde otro proceso.
Como son metadatos, se crean y se corrigen en producción igual que una pantalla: sin recompilar y sin redesplegar.
Menú → Formulario → Subgrid → Popup → Proceso → Resultado
navegación, seguridad, disposición, comportamiento y extensión, declarados, no programados
Tipos de paso
read
Recupera los registros sobre los que va a trabajar, con sus filtros y agrupaciones.
ask · validate
Pide al usuario lo que falte en un diálogo y comprueba las condiciones antes de continuar.
create · modify
Crea registros nuevos o actualiza los existentes, mapeando campo a campo.
invoke
Llama a un método propio o a un servicio externo cuando el paso no es un movimiento de datos.
output
Entrega el resultado: informe o PDF, XML, correo, etiqueta, ticket, otra pantalla.
Donde e-cometa trabaja hoy no hay esquemas de juguete: bases de datos Oracle con décadas de histórico, lógica en stored procedures y empresas de distribución que facturan mientras la aplicación cambia. Ahí el ciclo de ticket, desarrollo y despliegue llega tarde siempre.
El responsable que añade un campo de trazabilidad al albarán a las 7:00 lo tiene en la pantalla del almacén a las 7:01. Sin compilar, sin desplegar, sin ventana de mantenimiento. Ese requisito no se añadió después: es la razón por la que la plataforma se construyó así.
Por qué es diferente
Construido para esquemas reales, no para demos
01
Interfaces desde tus datos, no desde cero
ALS lee tu base de datos y expone una API REST automáticamente. e-cometa convierte esa API en grids, formularios y navegación. Una aplicación funcional desde el primer día, sin dibujar pantallas.
02
Modificaciones en producción sin downtime
Añadir un campo, cambiar una etiqueta, reordenar un formulario: se hace en el editor de metadatos. El cambio aparece en la próxima carga de página. Sin recompilar. Sin redesplegar.
03
Un despliegue, múltiples aplicaciones
Multi-tenant por diseño. Un servidor aloja aplicaciones completamente distintas configuradas desde un fichero de propiedades, y escala horizontalmente en Kubernetes sin multiplicar costes de infraestructura.
Java 17 · Spring Boot 3 · Vaadin 24 · ApiLogicServer · Kubernetes · Oracle / MySQL / MariaDB · PWA · LDAP / Keycloak
El 80/20, al revés
El modelo crece. El código, no.
Un generador cubre el 80 % y deja el 20 % restante atrapado en código a medida, para siempre. En e-cometa un requisito que se repite se absorbe en el modelo como una capacidad reutilizable, así que ese 20 % encoge con cada proyecto.
Esas capacidades las siguen construyendo desarrolladores: un carrito, una galería, un motor de workflow. El modelo sólo declara dónde y cuándo se usan.
incluirCarrito = true · tipoVisualizacionProducto = Galería
Disponible · MCP
Y ahora, háblale a tu ERP
Si la aplicación es el modelo, cambiarla es un problema de datos, y ahí un agente de desarrollo es fiable: e-cometa expone su catálogo de metadatos como servidor MCP, de modo que desde Claude o Cursor se crea un formulario, se añade un campo, se reordena una pantalla o se revisa un proceso en lenguaje natural, sin abrir el editor.
e-cometa ya tiene un editor de metadatos y funciona, pero para usarlo hay que conocer el modelo, y un cambio de verdad toca seis sitios: el formulario, la rejilla, la validación, el permiso, el menú y el proceso. El agente no aporta poder cambiar el modelo:aporta no tener que conocerlo.
Un agente que escribe Java puede producir cualquier cosa. Un agente que escribe metadatos sólo puede producir una aplicación.
Y no estrena poderes: un agente no tiene permisos propios, hereda los de quien se lo pide, y lo que propone se valida contra el esquema y se revisa como un diff antes de aplicarse. No es una superficie de ataque nueva, es otra forma de entrar por la que ya existe.
El servidor MCP en tu portátil está disponible hoy: lo arranca tu propio Claude, con tus credenciales y contra un proyecto. El servicio de equipo por HTTP, donde cada persona entra con su usuario y queda registrado cada cambio, es lo que viene después.
Solicitar acceso →tú
«Crea una pantalla de incidencias con fecha, prioridad y descripción, y añádela al menú de soporte.»
Claude · MCP e-cometa
- ✓ create_form · incidencias
- ✓ add_field · fecha, prioridad, descripción
- ✓ create_menu · soporte → incidencias
Visible en la próxima carga. Sin recompilar.
e-cometa-mcp · en tu portátil, por stdio · el agente lee y escribe modelo: formularios, campos, menús y procesos, más el wiki técnico
Comparativa
Por qué no Retool ni Appsmith
Son buenas herramientas. Pero tienen límites críticos cuando el esquema es real y los cambios son urgentes.
Ellos
Requieren que alguien dibuje cada pantalla a mano.
Las genera automáticamente desde los metadatos de tu base de datos.
Ellos
Un cambio requiere publicar una nueva versión.
El cambio está en los datos. No hay nada que publicar.
Ellos
El precio escala con el número de usuarios o editores.
Gratis para construir y para producción. Los usuarios de la aplicación no se pagan.
Clientes
En producción en sectores donde fallar no es una opción
Distribución industrial
Migración desde sistemas legacy sin reescribir lógica de negocio
Retail especializado
Cadena multi-punto de venta con gestión centralizada
Sector educativo
Gestión de centros con múltiples perfiles de usuario
Qué es tuyo y qué no
El runtime es código de confianza que ya tienes. El modelo es la parte que es tuya.
Hoy el modelo lo ejecuta Vaadin sobre Spring Boot, y los datos los sirve ApiLogicServer. Son piezas conocidas, probadas y abiertas: lo que corre por debajo no depende de que te fíes de nosotros.
Algún día lo ejecutará otra cosa, y eso no es una limitación: es exactamente la idea. Lo que no quieres reescribir la próxima vez no es el motor, es el conocimiento de tu negocio.
¿Tienes una base de datos? Ya tienes casi una aplicación.
En menos de una semana podemos tener una primera aplicación funcionando sobre tu BD. Sin compromisos. Sin migrar nada.
Habla con nosotros