The application is the model · On-premise · Open source coming soon
Your company has spent twenty years evolving.
Its software, three rewrites.
Every technology that carried your application was replaced whole, and the definition of how you work went with it. In e-cometa the screens and the business processes are not code: they are metadata sitting next to your data, edited in production and still there when the engine that interprets them changes.
Every technology we have ever put into production has expired.
Business knowledge never has.
you → Claude · e-cometa MCP "add an expiry date field to the items form and make it visible" Claude ✓ add_field · CR-Fields fieldName: expiryDate dataType: DatePicker visible: Y ✓ the user can already see the new field ✓ 0 rebuilds · 0 redeployments
0
redeployments to change a screen
1 JAR
hosts N isolated applications, multi-tenant
<1 week
to the first application running on your database
100%
deployable on-premise · open source coming soon
Turning Vaadin into a Dynamic Enterprise Platform Through Metadata
César Quinteiro Rendo (Intergal) presents the model behind e-cometa: metadata instead of code, business processes declared rather than programmed, multi-tenant isolation and Kubernetes scaling, with the numbers of an ERP in production.
15:15 CEST · Main Track
The underlying problem
Where does your business knowledge live today?
In eight places at once, each with its own format and its own owner. No versioning, no audit trail, and nobody able to say what changed, when and why.
if (role.equals("SUPERVISOR")) maxDiscount = 15;
Interface code
@PostMapping("/orders") checkCreditLimit(customer);
Backend services
CONSTRAINT ck_disc CHECK (discount <= 15)
Database constraints
PROCEDURE recalculate_rates( p_fortnight IN NUMBER)
Stored procedures
billing.cutoff_day=15 billing.retries=3
Configuration files
SUPERVISOR │ order │ UPD │ Y SALES │ order │ UPD │ N
Permission tables
H24 Special disc. 15 % H25 still valid?
A spreadsheet
“Before invoicing, check
the delivery notes of the 15th”A wiki page from 2019
And in the head of the person who has been here for twelve years, which is documented nowhere and retires one of these days.
Knowledge trapped in code dies with the stack that holds it up. Knowledge declared in a model migrates forward.
Fifty years drawing forms: first in code, then dragging components around a visual editor. The "screen" artefact is still there, separate from the data, drifting out of sync with every schema change and demanding a redeployment for every tweak.
e-cometa removes the artefact. There are no screens stored anywhere: there is metadata next to your data, and an engine that interprets it on every load. The interface always reflects the database because it derives from it. That is not an incremental improvement on drawing screens, it is no longer drawing them at all.
And no, this is not a configuration file on steroids: configuration tunes an application, metadata is the application. Readable by people, executable by machines, independent of whatever technology interprets it today, and in a single place.
Code gets rewritten. Metadata adapts.
Not just screens
Business processes are metadata too
A business application does not just read and edit records: it confirms orders, recalculates totals, generates the XML for the tax authority, issues reports, prints labels or sends email. In e-cometa all of that is a process: a sequence of steps defined in metadata, not programmed.
The flow branches on the outcome of each step, stops to ask the user for a decision and resumes where it left off. A process is triggered from a button on the grid or the form, on saving a record, when a report finishes, or from another process.
Being metadata, processes are created and corrected in production exactly like a screen: no rebuild and no redeployment.
Menu → Form → Subgrid → Popup → Process → Result
navigation, security, layout, behaviour and extension, declared rather than programmed
Step types
read
Retrieves the records the process will work on, with their filters and groupings.
ask · validate
Asks the user for whatever is missing in a dialog and checks the conditions before continuing.
create · modify
Creates new records or updates existing ones, mapping field by field.
invoke
Calls an internal method or an external service when the step is not a data movement.
output
Delivers the result: report or PDF, XML, email, label, receipt, another screen.
Where e-cometa works today there are no toy schemas: Oracle databases with decades of history, logic in stored procedures, and distribution companies that keep invoicing while the application changes. There, the ticket, development and deployment cycle is always late.
The manager who adds a traceability field to the delivery note at 7:00 has it on the warehouse screen at 7:01. No build, no deployment, no maintenance window. That requirement was not bolted on afterwards: it is the reason the platform was built this way.
Why it is different
Built for real schemas, not for demos
01
Interfaces from your data, not from scratch
ALS reads your database and exposes a REST API automatically. e-cometa turns that API into grids, forms and navigation. A working application from day one, without drawing screens.
02
Changes in production, with no downtime
Adding a field, changing a label, reordering a form: it is done in the metadata editor. The change shows up on the next page load. No rebuild. No redeployment.
03
One deployment, many applications
Multi-tenant by design. One server hosts completely different applications configured from a properties file, and it scales horizontally on Kubernetes without multiplying infrastructure costs.
Java 17 · Spring Boot 3 · Vaadin 24 · ApiLogicServer · Kubernetes · Oracle / MySQL / MariaDB · PWA · LDAP / Keycloak
The 80/20, the other way round
The model grows. The code does not.
A generator covers 80 % and leaves the remaining 20 % trapped in bespoke code, forever. In e-cometa a requirement that keeps coming back is absorbed into the model as a reusable capability, so that 20 % shrinks with every project.
Those capabilities are still built by developers: a shopping cart, a gallery, a workflow engine. The model only declares where and when they are used.
includeCart = true · productDisplayType = Gallery
Available · MCP
Now talk to your ERP
If the application is the model, changing it is a data problem, and there a coding agent is reliable: e-cometa exposes its metadata catalogue as an MCP server, so from Claude or Cursor you can create a form, add a field, reorder a screen or review a process in natural language, without opening the editor.
e-cometa already has a metadata editor and it works, but using it means knowing the model, and a real change touches six places: the form, the grid, the validation, the permission, the menu and the process. The agent does not add the power to change the model:it removes the need to know it.
An agent that writes Java can produce anything. An agent that writes metadata can only produce an application.
And it gains no new powers: an agent has no permissions of its own, it inherits those of whoever asks, and what it proposes is validated against the schema and reviewed as a diff before being applied. It is not a new attack surface, it is another way in through the one that already exists.
The MCP server on your laptop is available today: your own Claude starts it, with your credentials and against one project. The team service over HTTP, where each person signs in as themselves and every change is recorded, is what comes next.
Request access →you
“Create an incidents screen with date, priority and description, and add it to the support menu.”
Claude · e-cometa MCP
- ✓ create_form · incidents
- ✓ add_field · date, priority, description
- ✓ create_menu · support → incidents
Visible on the next load. No rebuild.
e-cometa-mcp · on your laptop, over stdio · the agent reads and writes the model: forms, fields, menus and processes, plus the technical wiki
Comparison
Why not Retool or Appsmith
They are good tools. But they hit critical limits when the schema is real and the changes are urgent.
Them
Someone has to draw every screen by hand.
Generates them automatically from your database metadata.
Them
A change requires publishing a new version.
The change is in the data. There is nothing to publish.
Them
Pricing scales with the number of users or editors.
Free to build with and to run. The people using the application are never charged for.
Customers
In production in sectors where failing is not an option
Industrial distribution
Migration from legacy systems without rewriting business logic
Specialist retail
Multi-store chain with centralised management
Education
School management with multiple user profiles
What is yours and what is not
The runtime is trusted code you already have. The model is the part that is yours.
Today the model is executed by Vaadin on Spring Boot, and the data is served by ApiLogicServer. They are known, proven, open pieces: what runs underneath does not depend on you trusting us.
One day something else will execute it, and that is not a limitation: it is exactly the point. What you do not want to rewrite next time is not the engine, it is the knowledge of your business.
Got a database? You almost have an application.
In under a week we can have a first application running on your database. No commitment. Nothing to migrate.
Talk to us