https://abap2ui5.github.io/insights/ Short essays about one idea: what happens when the ABAP server sends the screen instead of only the data. en Sun, 01 Nov 2026 01:49:54 GMT https://abap2ui5.github.io/insights/01-somewhere-on-the-way-to-ui5/ https://abap2ui5.github.io/insights/01-somewhere-on-the-way-to-ui5/ A table whose structure is only known at runtime, drawn in UI5 - how abap2UI5 binds data typed by the runtime type services without an entity type, and what a view without a contract costs. https://abap2ui5.github.io/insights/03-one-class-no-programming-model/ https://abap2ui5.github.io/insights/03-one-class-no-programming-model/ The one interface an abap2UI5 app implements, and why three save handlers - EML, a MODIFY, a BAPI - sit behind one unchanged UI class. https://abap2ui5.github.io/insights/04-no-annotation-in-between/ https://abap2ui5.github.io/insights/04-no-annotation-in-between/ Why the vocabulary of an abap2UI5 view is the UI5 control library itself - every control, at the UI5 version the bootstrap names - shown with a sap.m.Wizard. https://abap2ui5.github.io/insights/02-the-cost-of-a-screen/ https://abap2ui5.github.io/insights/02-the-cost-of-a-screen/ The smallest complete abap2UI5 app - one class, one interface, one URL parameter - and what has to exist beside it in the system, which is nothing. https://abap2ui5.github.io/insights/05-ui5-over-the-wire/ https://abap2ui5.github.io/insights/05-ui5-over-the-wire/ The one idea under abap2UI5: the backend answers every request with two strings, a UI5 XML view and its JSON model, and the browser renders them - UI5 Over-the-Wire. https://abap2ui5.github.io/insights/06-the-frontend-knows-nothing/ https://abap2ui5.github.io/insights/06-the-frontend-knows-nothing/ What the first GET delivers to the browser - a shell that renders a view and a model and knows no app - and why one shell serves every app in the system without a redeploy. https://abap2ui5.github.io/insights/07-one-handler-for-every-app/ https://abap2ui5.github.io/insights/07-one-handler-for-every-app/ Why no abap2UI5 app has a service of its own - one generic HTTP handler moves two strings for every app, and what the framework leaves to the apps to stay that small. https://abap2ui5.github.io/insights/08-only-the-changed-part/ https://abap2ui5.github.io/insights/08-only-the-changed-part/ Why the view is not sent on every click - an event changes the model alone, UI5 data binding updates the bound controls, and focus, scroll and half-typed input survive. https://abap2ui5.github.io/insights/09-a-new-instance-on-every-request/ https://abap2ui5.github.io/insights/09-a-new-instance-on-every-request/ Every request is a fresh instance of the app class - how z2ui5_t_01 carries the serialized instance forward, which attributes survive, and why a large attribute costs every click. https://abap2ui5.github.io/insights/10-swapping-the-view-at-runtime/ https://abap2ui5.github.io/insights/10-swapping-the-view-at-runtime/ A different control chosen in an IF - what follows when the view is a string the app produces per request rather than an artifact fixed at design time. https://abap2ui5.github.io/insights/11-no-build-no-deploy-no-cache/ https://abap2ui5.github.io/insights/11-no-build-no-deploy-no-cache/ What is missing from change, activate, refresh - no frontend build, no deployment path, no cache to invalidate - because the initial page and the frontend modules are answered from ABAP source. https://abap2ui5.github.io/insights/12-where-your-own-javascript-goes/ https://abap2ui5.github.io/insights/12-where-your-own-javascript-goes/ The three declared seams for JavaScript of your own - a control method called by id, expression binding in the view, a custom control in the z2ui5_ccc BSP - and why there is no plugin system. https://abap2ui5.github.io/insights/13-four-verbs-every-control/ https://abap2ui5.github.io/insights/13-four-verbs-every-control/ Why z2ui5_cl_ui5_view_builder has four methods - ele, tag, a, end - instead of one per control, what the completion list cost, and what the linter gives back. https://abap2ui5.github.io/insights/14-a-classrun-for-the-browser/ https://abap2ui5.github.io/insights/14-a-classrun-for-the-browser/ The shape abap2UI5 copied from if_oo_adt_classrun - one interface, one method, and it runs - and why a one-class app is one thing to read. https://abap2ui5.github.io/insights/15-where-the-selection-screen-went/ https://abap2ui5.github.io/insights/15-where-the-selection-screen-went/ What PARAMETERS did that the browser lost - the variable and the field as one declaration - and how _bind( ) puts them back together. https://abap2ui5.github.io/insights/16-one-click-one-request/ https://abap2ui5.github.io/insights/16-one-click-one-request/ The mental model under every abap2UI5 app - one click is one request and one call to main( ) on a fresh instance - and the three questions main( ) dispatches on, in order. https://abap2ui5.github.io/insights/17-what-the-client-can-do/ https://abap2ui5.github.io/insights/17-what-the-client-can-do/ The whole of z2ui5_if_client by shape - show a screen, bind data, read the event, navigate, message, follow-up actions - before knowing it by name. https://abap2ui5.github.io/insights/18-call-screen-leave-screen/ https://abap2ui5.github.io/insights/18-call-screen-leave-screen/ The app stack - nav_app_call( ) pushes an instance, nav_app_leave( ) pops it, get_app_prev( ) hands the caller the sub-app with its typed attributes - and where popups and the launchpad fit. https://abap2ui5.github.io/insights/19-where-f4-went/ https://abap2ui5.github.io/insights/19-where-f4-went/ Value help in three sizes - suggestion items filtered in the browser, a selection popup of the same class, a reusable value-help app on the stack - and what the DDIC link cost. https://abap2ui5.github.io/insights/20-message-still-works/ https://abap2ui5.github.io/insights/20-message-still-works/ Toasts, message boxes, sy, BAPIRET2 and exception objects - what carries over from classic messages, what an escaped exception does to the roundtrip, and check_hide_error_details. https://abap2ui5.github.io/insights/21-the-lock-is-gone-by-the-next-click/ https://abap2ui5.github.io/insights/21-the-lock-is-gone-by-the-next-click/ Why an ENQUEUE set while a screen opens is gone before the next click, and the patterns that replace it - lock at save, an optimistic check, a soft lock, a stateful session. https://abap2ui5.github.io/insights/22-who-may-start-which-app/ https://abap2ui5.github.io/insights/22-who-may-start-which-app/ One ICF node serves every app and the URL names the class - where authentication, authorization, the CSRF check and the Content Security Policy each sit. https://abap2ui5.github.io/insights/23-100-rows-four-hours-one-request/ https://abap2ui5.github.io/insights/23-100-rows-four-hours-one-request/ The three numbers behind abap2UI5 performance - the 100-row size limit of a list binding, the four-hour draft expiry, and what one request costs in instance and model size. https://abap2ui5.github.io/insights/24-abap-unit-for-a-screen/ https://abap2ui5.github.io/insights/24-abap-unit-for-a-screen/ Testing an abap2UI5 app in ABAP Unit without a client, HTTP or a browser - keep the logic out of client, call the handler methods directly, lint the view. https://abap2ui5.github.io/insights/25-when-one-class-is-not-enough/ https://abap2ui5.github.io/insights/25-when-one-class-is-not-enough/ The four seams of a larger abap2UI5 app - a class per screen on the stack, popups as classes, logic in a class without a screen, nested views - all of them ordinary ABAP. https://abap2ui5.github.io/insights/26-a-tile-like-any-other/ https://abap2ui5.github.io/insights/26-a-tile-like-any-other/ An abap2UI5 app in the Fiori Launchpad - the one shell BSP installed system-wide, the target mapping per app, what the app can read inside, and the blank tile after an import. https://abap2ui5.github.io/insights/27-one-codebase-702-to-abap-cloud/ https://abap2ui5.github.io/insights/27-one-codebase-702-to-abap-cloud/ Why abap2UI5 runs from NetWeaver 7.02 to ABAP Cloud from one codebase - the three utility classes that absorb the release differences, the generated 702 branch, and UI5 from the bootstrap. https://abap2ui5.github.io/insights/28-cloud-ready-is-a-property-of-your-app/ https://abap2ui5.github.io/insights/28-cloud-ready-is-a-property-of-your-app/ The framework is ABAP Cloud compliant, and that says nothing about the app - cloud-readiness is decided in the SELECT, a released CDS view against a database table. https://abap2ui5.github.io/insights/29-when-the-api-is-not-released/ https://abap2ui5.github.io/insights/29-when-the-api-is-not-released/ SAP's four clean core levels, where abap2UI5 sits (Level A), where an app lands by what it calls, and the wrapper that gives an unreleased API a name and a boundary. https://abap2ui5.github.io/insights/30-on-stack-or-side-by-side/ https://abap2ui5.github.io/insights/30-on-stack-or-side-by-side/ Two places to run the same app class - inside the SAP system, or on the BTP ABAP Environment against released remote APIs - and the lifecycle each one inherits. https://abap2ui5.github.io/insights/31-one-app-many-systems/ https://abap2ui5.github.io/insights/31-one-app-many-systems/ One side-by-side abap2UI5 app on the BTP ABAP Environment serving several S/4 systems - what makes it possible, and the tenant boundary the app has to enforce itself. https://abap2ui5.github.io/insights/32-from-its-to-abap2ui5/ https://abap2ui5.github.io/insights/32-from-its-to-abap2ui5/ Twenty-seven years of SAP user interfaces in one line - ITS, BSP, Web Dynpro, UI5 Freestyle, RAP, abap2UI5 - and which move did not reverse. https://abap2ui5.github.io/insights/33-rap-or-abap2ui5/ https://abap2ui5.github.io/insights/33-rap-or-abap2ui5/ The technical criteria for choosing RAP with Fiori Elements or abap2UI5 for a given screen - behavior against screen, EML from an abap2UI5 app, a runtime-typed model, the release floor. https://abap2ui5.github.io/insights/34-freestyle-or-abap2ui5/ https://abap2ui5.github.io/insights/34-freestyle-or-abap2ui5/ The technical criteria for choosing UI5 Freestyle or abap2UI5 - the four edges where the browser has to be smart, and the case where the backend already knows everything. https://abap2ui5.github.io/insights/36-written-for-agents/ https://abap2ui5.github.io/insights/36-written-for-agents/ Why a one-class, one-language app is the shape an AI coding agent handles best, and where the setup - the published page map, the linter, the MCP server, the sample catalogs - is documented. https://abap2ui5.github.io/insights/37-what-the-client-can-send/ https://abap2ui5.github.io/insights/37-what-the-client-can-send/ The threat model of an abap2UI5 app - what the browser chooses (the class, a draft id, the event, every bound value, startup parameters) and what the framework checks on each; the page a security review starts from. https://abap2ui5.github.io/insights/38-how-many-users/ https://abap2ui5.github.io/insights/38-how-many-users/ Sizing an abap2UI5 installation - one dialog work process per roundtrip, what a draft row holds, how z2ui5_t_01 grows and cleans itself, no server affinity, what a stateful session changes, what the roundtrip monitor measures. https://abap2ui5.github.io/insights/39-upgrading-the-framework/ https://abap2ui5.github.io/insights/39-upgrading-the-framework/ How abap2UI5 is versioned and upgraded - release tags, what is a stable contract (the public package), what the frozen package means, the deprecations page, pulling a tag with abapGit, the frontend branches, pinning, rolling back, what to re-test.