abapsheep

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.

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.

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.

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.

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.