Technical Insights
Thirty-six short articles about one idea: what happens when the ABAP server sends the screen instead of only the data.
Each one is about a coffee long, makes a single claim, and shows it in code wherever code can show it. Read one on its own and it stands. Read them in order and the four blocks add up to the whole picture — why the framework exists, how it works under the app, what a working day with it looks like, and where it belongs next to what SAP ships.
There is a good chance you will also pick up a few things about ABAP along the
way. RTTS, the dialog step, ENQUEUE, the selection screen, the ICF node, the
launchpad: this framework did not invent much, it just moved a lot of familiar
furniture into a browser, and half the fun is recognizing the room.
Everything turns on one axis:
One axis: when the definition of the screen stops being changeable.
Three ways to put a UI5 screen in front of a user on an ABAP stack, all three rendering in the browser with the same control library. UI5 Freestyle fixes the view at build time, as a file in a frontend project. RAP with Fiori Elements fixes it at activation time, as annotations on CDS. abap2UI5 fixes it when the request is answered, as a string an ABAP class produced for this request — and the next request may answer differently.
Everything else follows from where the view sits: what is deployed per app, what a screen costs in artifacts, what can still change at runtime, and which language it is all written in.
New here? Start with #2 The Cost of a Screen — it is the one that explains why anybody wrote this thing.
Why
What the framework is for, before how it works.
| #1 Somewhere on the Way to UI5, We Lost RTTS | a table whose structure is only known at runtime, drawn in UI5 |
| #2 The Cost of a Screen | why the thirty-line screen never gets built, and a whole one as a class |
| #3 One Class, No Programming Model | every API the system has, from BAPI to EML, behind one unchanged UI class |
| #4 No Annotation in Between | the vocabulary is the UI5 control library, all of it |
How It Works
The mechanism under the app, one piece per article. This is the block to read end to end if you like knowing why something works before you use it.
| #5 UI5 Over-the-Wire | every request answered with two strings |
| #6 The Frontend Knows Nothing | one shell for every app, and why it never needs a redeploy |
| #7 One Handler for Every App | no service per screen, and how small the handler is |
| #8 Only the Changed Part | the view stays, the model updates |
| #9 A New Instance on Every Request | serialized state, and what that asks of the class |
| #10 Swapping the View at Runtime | a different control, chosen in an IF |
| #11 No Build, No Deploy, No Cache | change, activate, refresh |
| #12 Where Your Own JavaScript Goes | three declared seams, no plugin system |
| #13 Four Verbs, Every Control | why the view builder knows no controls |
| #14 A Classrun for the Browser | the shape it copied |
| #15 Where the Selection Screen Went | the variable and the field are one declaration again |
A Working Day
What an ABAP developer meets in the first week, and how each old habit carries over — messages, locks, F4, authorizations, the launchpad tile.
| #16 One Click, One Request | PBO, PAI, and the dispatch in main( ) |
| #17 What the Client Can Do | the whole API surface, by shape |
| #18 CALL SCREEN, LEAVE SCREEN | the app stack, sub-apps and popups |
| #19 Where F4 Went | value help in three sizes |
| #20 MESSAGE Still Works | messages, exceptions, translation |
| #21 The Lock Is Gone by the Next Click | enqueue in a stateless world |
| #22 Who May Start Which App | one ICF node, authorization, CSRF |
| #23 100 Rows, Four Hours, One Request | the three numbers behind performance |
| #24 ABAP Unit for a Screen | testing the class, linting the view |
| #25 When One Class Is Not Enough | the seams of a larger app |
| #26 A Tile Like Any Other | into the Fiori Launchpad |
Where It Belongs
Releases, clean core, deployment shapes, and the honest comparison against the alternatives — including the cases where you should pick something else.
| #27 One Codebase, 7.02 to ABAP Cloud | why the release barely matters |
| #28 Cloud-Ready Is a Property of Your App | decided in the SELECT |
| #29 When the API Is Not Released | the clean core levels, and the wrapper |
| #30 On-Stack or Side-by-Side | two places to run, one class |
| #31 One App, Many Systems | a SaaS shape in ABAP |
| #32 From ITS to abap2UI5 | twenty-seven years in one line |
| #33 RAP or abap2UI5? | behavior against screen |
| #34 UI5 Freestyle or abap2UI5? | where the browser has to be smart |
| #35 Low-Code or abap2UI5? | designer against code |
| #36 Written for Agents | the consequence nobody designed |
The articles on how it works grew out of Under the Hood of abap2UI5 on the SAP Community, the long version in one piece.