S/4 Public Cloud

abap2UI5 runs on S/4 Public Cloud as an on-stack extension: it is written in the ABAP Cloud language version and uses released APIs only, so it passes the system's checks like any other ABAP Cloud development.

The setup in the BTP ABAP Environment is the same as in S/4 Public Cloud - both are ABAP for Cloud, both install through the ADT abapGit - so this page covers both. To install abap2UI5, follow these steps:

1. Install abap2UI5 with abapGit

S/4 Public Cloud supports only the ADT abapGit version. abap2UI5 contains only classes, interfaces, and tables, so you can pull it without issues.

Use the standard installation process with abapGit for Eclipse.

Two choices you cannot change later without relinking

Folder logic must be PREFIX. It is what .abapgit.xml declares, and the repository's package tree is built for it.

Keep the target package name short. abap2UI5 ships sub-packages two levels deep (src/00/01, src/01/04, …), and with PREFIX logic every derived sub-package name starts with the name you pick here. ABAP caps a package name at 30 characters, so a long root leaves the deeper ones no room — the pull then fails and the repository has to be unlinked and linked again against a shorter package. Something like ZABAP2UI5 is plenty.

A status bar shows the progress of the pull operation:

After a moment, the installation completes:

2. Mass Activate the Imported Artifacts

When installing repositories with ADT abapGit, all artifacts arrive inactive. Activate them manually. The simplest approach: create a dedicated inactive/active folder tree for the abap2UI5 project:

Trigger the mass activation for all inactive artifacts. Some objects may refuse to activate on the first pass because something they depend on is still inactive — repeat the mass activation, or force it, until the list is empty:

When activation completes, refresh the folder tree:

Now you'll see that all artifacts are active:

3. Set Up the HTTP Service

Build an HTTP handler manually or use the cloud branch of the frontend repository.

Important: In S/4 Public Cloud, accessing the HTTP endpoint needs S_DEVELOP authorization. This is the quickest way to test in development environments, but makes the scenario unfit for production.

For production, finish the frontend deployment and tile configuration in the steps below.

4. Deploy the UI5 App (Optional)

Up to here the HTTP service is enough — you can open it and use abap2UI5 with a developer role. Deploying the app is what makes it reachable for business users, through a Launchpad tile.

ADT abapGit cannot import a UI5 app (BSP), so this step runs from VS Code with the SAP Fiori Tools extension pack instead.

1. Clone the branch that matches your stack — cloud for the classic UI5 runtime, cloud_v2 for the legacy-free one (UI5 2.x preview), or cloud_new, which carries no copy of the frontend: its app is one view with one z2ui5.embed.Container that loads the frontend from the backend at run time, so an abap2UI5 update needs no new deployment of the app. cloud_new needs an abap2UI5 newer than 1.146.0 and exists since 1.147.0; the trade-off is that the frontend is fetched from the HTTP service on every page load, and the legacy-free runtime is not covered by it yet. Every branch uses the same service, objects and launchpad settings, so a system switches by deploying another one:

   git clone --branch cloud --single-branch https://github.com/abap2UI5/frontend.git

2. In the app folder, open the Fiori Application Info page and add a deployment configuration pointing at your system. Keep the target package name short here too.

3. Add a Launchpad configuration in the same place. It writes the descriptors that let a tile start the app; pick the semantic object and action that suit your scenario.

4. Deploy.

Where the deployed app sends its requests

Only the separately deployed app needs this — when the backend serves the page itself, it tells the frontend to post back to the same URL.

The cloud, cloud_v2 and cloud_new branches ship sap.app.dataSources.http.uri as /sap/bc/http/sap/z2ui5, the path an HTTP service with ID Z2UI5 is published under. If you created the service under a different ID, change that entry in manifest.json to match — otherwise the POSTs go to a service that does not exist and the app fails with a 403 ICFEUCONFORBIDDEN (UCON) error, which does not say which URL it was.

The on-premise branches (standard, standard_v2, standard_new) use the SICF path /sap/bc/z2ui5 instead.

5. Give Business Users Access (Optional)

Opening the HTTP service directly works because a developer has S_DEVELOP. A business user has not, so the app has to be reached through a tile — which means one chain of objects, each published locally before the next one can see it:

LADI → IAM App → Business Catalog → Business Role → Space, Page, Tile

1. Launchpad App Descriptor Item (LADI) — create it and add the navigation parameters naming the app to start.

   The id has to be UPPERCASE

   A lower-case id is rejected, and the form editor may refuse to save without making clear why. Use Open With → Source Editor to edit the descriptor directly.

2. IAM App — create one, include the HTTP service, add the LADI from step 1, and publish locally.

3. Business Catalog — link the IAM App to it and publish locally.

4. Business Role — add the business catalog to a role in the ABAP Launchpad.

5. Space and page — create them and place the tile, so the user has somewhere to click.

SAP's tutorial Integrate List Report into ABAP Fiori Launchpad covers the generic mechanics of the IAM app, the business catalog and the business role, and the SAP Help page Launchpad App Descriptor Items the descriptor item.

A walkthrough with screenshots

Warren Eiserman documented a full first install of this scenario, step by step and with screenshots of every dialog: UI5 in ABAP Cloud (without RAP or Fiori Elements). Several of the warnings on this page come from that write-up.

BTP ABAP Environment

BTP ABAP Environment shares the same technical base as S/4 Public Cloud. The instructions above work for both systems.