Everything in the atlas

SAP's own guidance is narrower than the service's reach: it names standalone, single-tenant applications that do not connect to other applications as the fit, and says to stay on [the HTML5 Application Repository](artifact:btp-html5-application-repository) and the application router where those meet your needs better. Four hard limits decide it before taste does — 300 requests per second per subaccount, ten retained versions per application, 100 MB per application and 400 MB for the deployment archive.

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.

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.

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.

No published releases; repository quiet for 32 months.

No published releases; repository quiet for 28 months.

No published releases; repository quiet for 54 months.

No published releases; repository quiet for 43 months.

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.

Texts that must not leave the organisation: the file is uploaded to the site to be translated, and neither the tool's page nor the site's data protection notice says where it is processed or how long it is kept.

2 of 8 plans deprecated.

No published releases; repository quiet for 79 months.

No published releases; repository quiet for 93 months.

No published releases; repository quiet for 88 months.

No published releases; repository quiet for 28 months.

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.

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.

This is the legacy edition, for on-premise systems from SAP_BASIS 7.40. On ABAP Cloud, [the Cloud Edition](artifact:sap-code-pal-for-abap-cloud) is the one that runs.

No published releases; repository quiet for 67 months.

Not reachable since 2026-10-20.

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.

No published releases; repository quiet for 31 months.

Not reachable Not reachable since 2026-10-20.

Functional boundary The Level A–D grade merges SAP's two published files in the tool's own engine: it is an orientation rather than an ATC result and is left out of the signed audit pack, and the repository documents state by state where the grade is expected to differ from what the clean core ATC check reports. Nothing here runs ABAP Unit — on the RAP track that result is recorded from your own SAP system, and generated CAP tests run against mocks in an isolated runner rather than in a real SAP S/4HANA system. Tenants, organisation accounts, single sign-on, a self-hosted edition and write access through an API are deliberately not built, and one account has five analysis runs before a Gemini API key of its own is needed.

Neither the package manifest nor the repository tree declares a licence.

The maintainer states it is unofficial, not endorsed by SAP, and that it uses authenticated Hub web and catalogue endpoints and browser session cookies in ways SAP's terms of service, SAP account terms or an organisation's own policies may restrict. The same README asks the reader not to use it for production, broad distribution or shared access without explicit approval, and says that installing it grants no permission to automate SAP services.

Neither the package manifest nor the repository tree declares a licence.

It needs an S-user with SAP Support Portal access, so there is nothing to search without a support contract behind the login. The maintainer states it uses private SAP APIs behind authentication, asks the reader to check whether that use breaches SAP's terms of service, and disclaims both liability and any guarantee that it keeps working. MFA is handled only by typing the code into a visible browser, so a headless deployment cannot complete a login that demands one.

What it returns is planning material, not a commitment, and the monorepo labels the server's role "future/planned features (planning only)". The maintainer also states it is unofficial, not endorsed by SAP, and that it uses authenticated Road Map Explorer web endpoints and browser session cookies in ways SAP's terms of service or an organisation's policies may restrict, with production, broad distribution and shared access called out as needing explicit approval. An account that requires MFA has to be bootstrapped once through a visible browser.

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

A client that cannot reach the adt ICF service over HTTP has nothing to call.

Neither the package manifest nor the repository tree declares a licence.