Insights

What happens when the ABAP server sends the screen instead of only the data.

38 short essays, each making a single claim and showing it in code wherever code can show it. Read one on its own and it stands. Read them in order and the parts add up to the whole picture — what the framework rests on, how it works under the app, what a working day with it looks like, and where it belongs in the landscape. They are the “why it works like this” for a developer and an architect.

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.

Three ways to put a UI5 screen in front of a user on an ABAP stack, ordered by the moment the view is fixed: UI5 Freestyle at build time, RAP with Fiori Elements at activation time, abap2UI5 when the request is answered.
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.

Three ways in

All 38, in reading order

New here? Start with #5 UI5 Over-the-Wire, the one idea everything else is a consequence of, and #16 One Click, One Request, the mental model every app is written against.

What It Rests On

The two properties that come before the mechanism: a model that may be typed at runtime, and an app that is one class with no programming model around it.

  1. #1Somewhere on the Way to UI5, We Lost RTTSa table whose structure is only known at runtime, drawn in UI5
  2. #3One Class, No Programming Modelevery API the system has, from BAPI to EML, behind one unchanged UI class
  3. #4No Annotation in Betweenthe vocabulary is the UI5 control library, all of it

The First Example

The smallest complete app, read line by line — and nothing beside it.

  1. #2The Cost of a Screena whole application as one class, and what has to exist beside it

How It Works

The mechanism under the app, one piece per article. The block to read end to end if you like knowing why something works before you use it.

  1. #5UI5 Over-the-Wireevery request answered with two strings
  2. #6The Frontend Knows Nothingone shell for every app, and why it never needs a redeploy
  3. #7One Handler for Every Appno service per screen, and what the handler leaves to the apps
  4. #8Only the Changed Partthe view stays, the model updates
  5. #9A New Instance on Every Requestserialized state, and what that asks of the class
  6. #10Swapping the View at Runtimea different control, chosen in an IF
  7. #11No Build, No Deploy, No Cachechange, activate, refresh — and where a BSP still enters
  8. #12Where Your Own JavaScript Goesthree declared seams, no plugin system
  9. #13Four Verbs, Every Controlwhy the view builder knows no controls
  10. #14A Classrun for the Browserthe shape it copied
  11. #15Where the Selection Screen Wentthe 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.

  1. #16One Click, One RequestPBO, PAI, and the dispatch in main( )
  2. #17What the Client Can Dothe whole API surface, by shape
  3. #18CALL SCREEN, LEAVE SCREENthe app stack, sub-apps and popups
  4. #19Where F4 Wentvalue help in three sizes
  5. #20MESSAGE Still Worksmessages, exceptions, translation
  6. #21The Lock Is Gone by the Next Clickenqueue in a stateless world
  7. #22Who May Start Which Appone ICF node, authorization, CSRF, the CSP
  8. #23100 Rows, Four Hours, One Requestthe three numbers behind performance
  9. #24ABAP Unit for a Screentesting the class, linting the view
  10. #25When One Class Is Not Enoughthe seams of a larger app
  11. #26A Tile Like Any Otherinto the Fiori Launchpad

Where It Belongs in the Landscape

Releases, clean core, deployment shapes, and the technical criteria that decide between abap2UI5, RAP and UI5 Freestyle for a given screen.

  1. #27One Codebase, 7.02 to ABAP Cloudwhy the release barely matters
  2. #28Cloud-Ready Is a Property of Your Appdecided in the SELECT
  3. #29When the API Is Not Releasedthe clean core levels, and the wrapper
  4. #30On-Stack or Side-by-Sidetwo places to run, one class
  5. #31One App, Many Systemsseveral S/4 systems behind one app, and the boundary the app draws
  6. #32From ITS to abap2UI5twenty-seven years in one line
  7. #33RAP or abap2UI5?behavior against screen, and EML from an abap2UI5 app
  8. #34UI5 Freestyle or abap2UI5?the four edges where the browser has to be smart
  9. #36Written for Agentswhy one class in one language suits an agent

Running It

What an architect asks before an installation goes productive: the threat model, the sizing, the upgrade.

  1. #37What the Client Can Sendthe class, the draft id, the event, every bound value — and what is checked
  2. #38How Many Userswork processes, draft rows, no server affinity, what the monitor measures
  3. #39Upgrading the Frameworkrelease tags, the stable contract, the frozen package, pull, pin, roll back

The essays on how it works grew out of Under the Hood of abap2UI5 on the SAP Community, the long version in one piece.