oblomov-dev

The page and the [abap2UI5](artifact:abap2ui5-abap2ui5) service have to share an origin: an `endpoint` that resolves to another origin is refused, and abap2UI5 rejects a POST whose `Origin` names another host. A host that routes by the URL hash, such as a Fiori elements app or an app with a UI5 router, needs abap2UI5 1.146.0 or later, because 1.145.0 clears the host's hash after every roundtrip. One frontend per page: the first control that starts decides which endpoint the frontend comes from.

Event roundtrips and visual fidelity stay with a live run: the documentation leaves those to the project's MCP server and to [abap2UI5 for VS Code](artifact:abap2ui5-vscode-extension). A class that builds view parts in helper methods without the handle idiom cannot be statically reconstructed, and the render gate is then skipped with a notice while the property gate runs on what was reconstructed. A screenshot is not a preview of the app: nothing round-trips, no event reaches ABAP, and a table filled by a SELECT photographs empty unless a mock JSON file sits beside the source.

Every gate here runs off-system, so what the class does on a real system and what the view does on the oldest UI5 release it has to serve are what the `pitfalls` catalogues carry and no local run can see. It runs abap2UI5 app classes, so ABAP that is not one has nothing here to deploy into. In system mode the sandbox tools are not offered, and an `app_act` event runs on the system as the configured user.

The embedded preview needs a system that accepts basic auth: the documentation states that pure SSO or SAML without a basic-auth fallback is not supported, and points at `external` mode, which opens the app in the normal browser with the existing SAP session. On the web only the language half runs; the preview with its proxy, traffic log and screenshot, Ctrl+F3 activation, the render gate, the workspace-wide check and the MCP servers are desktop-only. The agent app tools send nothing until `abap2ui5.agent.enableAppTools` is switched on in User settings, because an event they fire runs as the configured user and changes data on the system for real.

Stateful apps cannot be operated: a stateful session lives in one HTTP request and an MCP call is one request, so `app_start` refuses them. The repository carries no release yet and states the addon has not been run in production use, the 7.02 downport is lint-only with no 7.02 system having run it, and the ABAP Cloud HTTP service setup is written down but still to verify on your own system.

Not a way to run existing reports unchanged: a report is rewritten as a class, and `CALL SCREEN`, dynpro modules, batch input, `SUBMIT` and native SQL are refused by the converter rather than mapped. Not an SAP GUI in the browser either: the programming model is classic and the screens are UI5, and the README points at abap2UI5-addons/sapgui for SE16N or SM37. Output has gaps the README names — ALV cells show dates and times as the model carries them rather than in the user's format, print is a text file because ABAP Cloud has no spool, and value tables for F4 are read on premise only.

The frontend is optional: where abap2UI5 apps are reached through the framework's own HTTP service, nothing from here is installed. In S/4 Public Cloud that endpoint needs `S_DEVELOP` authorisation, which the installation guide states makes it unfit for production, and the separate frontend app with an extra tile is what it names for business users. The `cloud_new` and `standard_new` branches need an abap2UI5 newer than 1.146.0 on the system.

Not for views built from controls outside the portable profile: sap.ui.table, sap.f, sap.uxap, sap.ui.comp and z2ui5.cc custom controls render as a visible unsupported-control box and are listed in the diagnostics, and `CONTROL_BY_ID` and `BINDING_CALL` stay unsupported. Nine frontend actions the profile allows, `DOWNLOAD_B64_FILE` and `SYSTEM_LOGOUT` among them, are skipped and reported rather than run, and formatters other than the profile's `Formatter.Date*` render a placeholder.

There is no control tree: visibility and enablement are not evaluated, and `set_value( )` is not checked against the bound paths. The frontend `CONFIG` (device, UI5 version, focus, scroll) is not sent at all, so an app that branches on device or theme sees initial values. It drives `z2ui5_cl_ui5_handler` and the draft service, which the README states are not part of abap2UI5's released API in `src/02`, so a core change there can require a change here.

The class has to be moved by hand: an abapGit pull of the exported ZIP, or a paste into ADT or SE24. The palette is held to the 121 controls of UI5 1.71, and a control inserted by its class name instead comes from whatever UI5 the canvas has loaded, with nothing checking it against 1.71 - *Checks* reports that. An app class that builds no view, or more than one, is refused.

A `SELECT` from a business table has nothing to select from: the database in the page holds the framework's own tables, and nothing can reach outside the browser, so an app that reads a system's data cannot be tried here. Only the UI5 libraries built in are available and a control from anywhere else will not load; what the transpiler cannot compile is reported in the output panel rather than run. State lives in the tab — a reload, and a press of Run, starts over on a fresh database.

Neither suite has been run against an ABAP system: the reference backends are the framework transpiled to Node and cap2UI5 on CAP, so what a check does on a real system is open. The portable profile is a subset of 61 controls, filled from a census of 247 core apps of which 64.8 % run unchanged, so an app outside it renders placeholders in the terminal and Adaptive Cards renderers.

A sample that needs something the system provides is not here — the samples-stack repository holds the OData, RAP, WebSocket and launchpad demos, and samples-controls the rebuilds of the UI5 Demo Kit originals. Every class in `src/` keeps to controls and properties available since UI5 1.71 and not deprecated, apart from two clipboard samples marked `(UI5 1.119+)`, so a newer control is not demonstrated here. Numbers are handed out per repository and reused across the three, so `493` alone does not name a sample: `Z2UI5_CL_SMP_APP_493` is the Hello World here.

Not on ABAP Cloud: most of the libraries use APIs that are not released there, and the repository has no ABAP Cloud gate yet. Not beyond a development system without authorisation checks added first — the samples carry none of their own, the abap-fm-logger sample reads the log table `ZAFL_LOG` with whatever the logged calls received and returned, and the abap_fm_json sample calls function modules, limited to a hard-coded whitelist.

The value-help and search-help popups read whichever DDIC check table the user selects without an authorisation check of their own, so the README asks for your own checks and a restriction on which tables may be browsed before they are used beyond a development system. The transport-request popup works only on-premise, and the search help does not yet run on the Cloud stack.

Not an end-user app: it reads from any table the user names and writes into tables of the Z/Y namespace, with no authorisation check of its own, so the README asks a project to add its own checks on `S_TABU_DIS`/`S_TABU_NAM` and to restrict who may run it before it is used beyond a development system. XLSX upload and download are not ready for ABAP Cloud yet, and of the upload apps only the JSON one writes the file's rows back to the database.

Not where the framework code itself has to change: `input/` and the three installable branches are overwritten by the workflows on every upstream push, and a framework change is a pull request to abap2UI5. Bug reports and feature requests also go to the abap2UI5 repository rather than this one.

The 221 ports under `src/02` need a UI5 runtime newer than 1.71: they install and activate on any release, and on an older UI5 the newer control does not render. The `src/03` collection is hand-written for SAPUI5-only controls and needs a SAPUI5 bootstrap. There are no per-library branches, so pulling the whole repository is the one way in and the activation takes a few minutes.

Not the place to learn abap2UI5 itself: every package starts from a technology the system already provides, and the framework basics and the control gallery are the other two sample repositories, abap2UI5/samples and abap2UI5/samples-controls. Three packages are out of reach on ABAP Cloud, and `05` needs the 2021 release that carries RAP business events.

It sees [abap2UI5](artifact:abap2ui5-abap2ui5) only: the figures come from the framework's HTTP handler, its monitor hook and its draft table, so nothing outside abap2UI5 appears in them. The usage, error and performance tabs stay empty until the handler line is in place or the user exit sets `check_monitor_active`. Recording which employee used which application, when and how fast, is subject to works council co-determination in Germany (§ 87 (1) no. 6 BetrVG); user tracking is `HASH` by default, `NAME` stores user names, and the request recorder keeps the complete request and response of every roundtrip for two days by default.

`APP_TITLE` is not applied by the exit: the `title` field was removed from `z2ui5_if_ui5_exit=>ty_s_http_config` in abap2UI5 1.145.0, so an app that wants it as its browser tab title sets it while it runs. The live theme preview runs the frontend action `THEMING` / `setTheme` and needs UI5 1.118 or later; on an older release a saved theme applies with the next page load. The code is written for ABAP 7.50 and the README states there is no downported 7.02 version, no 702 branch and no workflow that builds one.

Needs Standard ABAP 7.50 or higher, and an abap2UI5 whose frontend reserves the resourceRoot `z2ui5_cci`: a frontend predating that rename reserves `z2ui5ccc` and cannot resolve the controls. Frontend artefacts only one company needs, such as an in-house reuse library, a corporate icon font or company CSS, are what [abap2UI5-addons/custom-controls-customer](https://github.com/abap2UI5-addons/custom-controls-customer) is for, the same mechanism under the second reserved root `z2ui5_ccc`. ExportSpreadsheet needs SAPUI5: under OpenUI5 `sap.ui.export` is missing and the button renders disabled.

Stateful apps do not work through it: an app calling `client->set_session_stateful( )` needs the ICF session of the system it runs on, and the consumer opens a new HTTP connection per request without forwarding the `sap-contextid` header that addresses that session. Request headers do not cross either, and a user exit on the source system sees the path of the node `/sap/bc/z2ui5_http_srv` rather than the consumer's. For ABAP Cloud there is only the `cloud` branch, which the README describes as an unmaintained prototype from 2025-11, consumer side only and with no CI.

There is nothing here for ABAP for Cloud: the requirements name Standard ABAP releases only, and a CDS/SADL based OData service for `ABAP for Cloud` compatibility stands under Limitations & Todo.

The layout is rendered into an [abap2UI5](artifact:abap2ui5-abap2ui5) view and its events are passed on from the app's `main` method, so there is nothing here for a UI outside an abap2UI5 app. Shared layouts stay denied until a class implementing `z2ui5_if_layo_auth` exists in the system, so an installation whose key users are to maintain shared layouts has that class and its authorization object to write first.

Where the release and programming model offer durable locks, as RAP draft handling does, the README states that those solve the problem at the kernel level and the lock manager is for where that is not an option. A running handler occupies one background work process for as long as any lock is held, and only generated `ENQUEUE_*` modules can be locked.

Not the whole addon in ABAP Cloud: the DDIC annotation service is not released there, so the annotations come through XCO instead, a database table is read-only, the DDL source is not read, and the cloud path was written without a cloud system to run it on. Not for a plain internal table, since it renders from CDS annotations; the README points at `z2ui5_cl_ui5_view_builder` for that case. As of 2026-10 the maintainer states that none of it has been clicked through in an SAP system: the RAP write path and the reading of metadata extensions were written from documentation and pass the three offline gates only.

For an app that calls `client->set_session_stateful( )`, which needs the ICF session of the system it runs on; apps keeping their state in the draft table, the abap2UI5 default, work unchanged. For an app that reads a request header through the user exit on the source system, because the consumer forwards method, body, path, query string and status, not headers.

Not on ABAP Cloud: the system tables and the classic Workbench APIs the screens use are not released for the ABAP Cloud language version, and there is no 7.02 version below the 7.50 floor either. Not where the full original function is needed, since only the listed transactions exist and about 300 buttons and fields are shown disabled. The authorization checks are rebuilt rather than the originals, which is why the README asks that the screens be tried with a restricted user on a sandbox before the ICF service is opened to more people.

Not as it stands on a system past development: it reads the contents of any table the user names without an authorisation check of its own, so access is bounded only by whatever restrictions exist on the underlying handler or service. The README asks for your own checks first, naming `AUTHORITY-CHECK` on `S_TABU_DIS`/`S_TABU_NAM`, and for a restriction on who may run the app. There is no 7.02 downport either, because the selection-screen dependency has no `702` branch.

The `PARAMETERS`-style selection screen with event blocks is not here: `z2ui5_cl_sel_screen` and `z2ui5_cl_sel_screen_sel` are a skeleton whose methods are still empty, and the README points at [abap-cloud-gui](artifact:abap2ui5-addons-abap-cloud-gui) for a full report-style screen.

It runs whatever SQL a user types without an authorisation check of its own, and the native path additionally uses ADBC, which bypasses ABAP authorisations and client separation; the README asks anyone running it beyond a development system to add authorisation checks and restrict who may start the app. The native console needs Standard ABAP, so on ABAP Cloud only the Open SQL console is available.

The app writes to whatever table is passed in the URL parameter `table` and carries no authorisation check of its own, so past a development system it needs authorisation checks added and a restriction on who may run it.

It is not the framework and takes no framework fixes: those belong upstream in abap2UI5, and nothing under `src/`, `downport/`, `output/` and `build/` here is a source file. The build is frozen on pinned commits with no scheduled rebuild, so it does not show what abap2UI5 main does today, samples in subfolders of the samples repository are excluded because they require a real SAP system, and a known upstream transpiler issue leaves `check_on_init( )` always false, so backend-built view XML may not be returned.