Everything in ABAP

Only on SAP S/4HANA 2023 and 2025, on premise or private cloud: [SAP S/4HANA Cloud, Public Edition](external:sap-s4hana-cloud-public-edition) and the [SAP BTP ABAP environment](artifact:btp-abap-environment) are listed as coming soon, and a 2023 system has to leave out `ZABAP_PRC_EVENTS_SE_2025`, whose event-based side effects rely on APIs released with S/4HANA 2025. Not for a system that already carries a copy, because object names are global and two versions cannot live side by side, and not for a productive system by way of the `ZABAP_PRC_DEMO*` packages, which the README states are not intended for one and whose init classes delete and rebuild their own tables on every run. While the major version is 0 the public API is not stable: minor bumps carry breaking changes with no deprecation period, so productive use means pinning a tag and reading the CHANGELOG before every upgrade.

The generated files are copied or deployed into the ABAP system by hand, the fourth step of its own usage list, so nothing keeps an activated service in step with the model it was generated from. Its peer dependency is `@sap/cds` ^9.8, so it does not install into a project on an earlier CAP release.

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.

Not a system to run a business application on: there is no business application in it, and what it implements of the language, the dictionary and Gateway is a stated subset of each. It is a clean-room reimplementation of the `/IWBEP/` interfaces that bundles no SAP source and no standard DDIC, so a service that reads standard objects has nothing to read, and `ANORMALIES.md` records every place the runtime differs from SAP before any workaround is written.

On an [SAP BTP ABAP environment](artifact:btp-abap-environment) system only the generated code is left: DDIC creation is not supported on ABAP Cloud, because classic DDIC object creation over REST is not available there. Create DDIC is also disabled where ADT is not installed in the same Eclipse, and Insert into Editor then works with any editor implementing `ITextEditor` instead of the ABAP one.

The project states that until v1.0.0 is reached, breaking changes may occur without prior notice. Rule items do not chain: every rule operates on the original input string, so a format whose second step needs the result of the first needs a custom logic class. A REPLACE rule whose replacement produces the exact same string as the input is reported as `no match`, which the documentation records as a known limitation.

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.

Server side only, and deliberately: the author states there is no realistic way to support the SSE streaming a client needs, so there are no notifications, no `listChanged`, no `subscribe` and no logging. It is also frozen — protocol versions up to 2025-11-25 and no further, with everything after that in a separate V2 SDK, so starting here today is starting on a closed branch.

Stateless by design: with no `Mcp-Session-Id` and no SSE, notifications of any kind, `resources/subscribe` and stream-close cancellation are excluded, which the author states are protocol-level impossibilities on stateless ICF rather than gaps to be filled later within this design. ABAP Cloud is not supported and not planned, the stated reason being SAP pushing its own MCP strategy and features in BTP; the first iteration targets 7.5x classic, with 7.02 to 7.4x served from a separate generated downport repository. No authorization object and no default auth check are delivered, so a user who may call the ICF node may call every `AREA`/`SERVER` registered under it until `check_authorization` is redefined.

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.

LISA does the translation step only: it does not discover objects or manage transports, and its README pairs it with [an ADT MCP server](artifact:sap-adt-mcp-server) for those. Every write needs a transport request, and which object types it can write differs between public cloud or [the SAP BTP ABAP environment](artifact:btp-abap-environment) and on-premise or private cloud, and by release. Running it locally is meant for development and testing, not production.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.