#7 One Handler for Every App ​

Count what a screen usually costs in backend artifacts. A CDS view or two, a service definition, a service binding, a behavior definition and its implementation, a projection — each one named, transported, reviewed, and each one belonging to exactly one application. Then multiply by the number of screens your team ships in a year.

An abap2UI5 app adds none of them — and there is no SEGW project underneath either. Every app in the system is served by the same generic HTTP handler, and it is generic in a specific way: it does not know the app, the view or the model. It moves two strings.

A service per screen, against one handler that knows none of them.

That is visible from inside, and it is the first thing worth trying in a debugger. Set a breakpoint in an app class and look at the call stack — there is one frame between the app and the handler. No OData runtime, no SADL, no Gateway. The stack fits on a screenshot.

The reason it can be generic is that nothing about the data is agreed in advance. In an OData conversation the metadata comes first and fixes the shape; data follows within that shape for the rest of the session. Here the model travels with every response — #5 — so each response may carry a different one. There is no contract to violate because there is no contract to register.

How Much Handler That Is ​

The communication core of abap2UI5 is one HTTP handler class, two interfaces and one database table. Originally about 2,300 lines of ABAP. The framework has grown since — most visibly the optional view builder — but the part that carries every request is still that.

It is small because of what it leaves to the apps. The framework does not build views; apps do. It does not decide program flow; apps do. It does not wrap UI5 controls, so it does not grow when UI5 does. It does not implement a protocol, because the protocol is a POST with two strings.

That has a practical consequence, and it is the one that decides whether a framework gets through a review at all. Something sitting in the request path of a business application sees every input, every response and every user, and a dependency that cannot be read cannot really be reviewed. Here one class holds the logic, and reading it is an afternoon. The audit answers are short for the same reason: no CDS artifacts, no RAP objects, no generated code, no build step, no transitive package tree. The system footprint is the source in the repository.

What that removes is not effort — the app still decides everything — but artifacts. A screen stops being a set of objects to create, name, transport and govern, and becomes a class.

A handler that knows nothing about the application never has to be written again for the next one.