Technical Insights

The knowledge behind abap2UI5, cut into pieces that each fit one coffee. Every article makes one claim, shows it in code where code can show it, and can be read on its own — but read in order, 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.

The axis the whole series turns on is this one:

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 artefacts, what can still change at runtime, and which language it is all written in.

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 abap2UI5 Is Not a Programming Model	one interface, one method, and no opinion about what is behind the screen
#3 The Cost of a Screen	why the thirty-line screen never gets built, and a whole one as a 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.

#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 habit carries over.

#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 choice against the alternatives.

#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?	behaviour 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.