abap2UI5 frontend
The abap2UI5 frontend as installable ABAP artefacts: per system type one generated branch carrying the BSP or HTTP service with its handler, pulled into the system with abapGitabapGitA Git client written in ABAP that runs inside the system, so objects are cloned, pulled and pushed without leaving it; with no package manager in ABAP, a cloned repository is how code is distributed.community org, abap.
abap2UI5 apps run through the framework's own HTTP service, and this repository publishes the separate frontend app a system installs beside it: one branch per system type, carrying the BSP Z2UI5 or the HTTP service Z2UI5 with its handler class and ICF nodes. Six branches are published: cloud, cloud_v2, standard and standard_v2 carry a generated copy of the abap2UI5 webapp, while cloud_new and standard_new carry one view with the z2ui5.embed.Container control, which loads the frontend from the backend it runs against, so an abap2UI5 update needs no frontend pull. Every branch names the same objects and the same launchpad component z2ui5, so a system switches by pulling another branch into the same abapGit repository and launchpad target mappings keep working. Nothing here is written by hand: every branch is built in abap2UI5abap2UI5One ABAP class implementing z2ui5_if_app is the whole app: the browser loads a generic UI5 shell once, and every interaction after that is an HTTP roundtrip back into ABAP.community org, abap from app/webapp and frontend/ and pushed in, and the guard check fails every pull request opened here.
Facts
Where it sits
Who is behind it
In the atlas: maintains 18@abap2UI5maintainerabapsheepContributes to this
In the atlas: contributes to 6@abapsheepaxelmohnenContributes to this
In the atlas: contributes to 4@axelmohnenChristian GünterContributes to this
In the atlas: maintains 1, contributes to 12@christianguenter2oblomov-devContributes to this
In the atlas: maintains 4, contributes to 44@oblomov-dev4 contributors
Before choosing this
Conditions
PracticalFunctional boundary
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.
What it declares
Every artifact
- Type
- Package
- Origin
- By a community org
As a package
- Where it runs
- does not say
- Distributed through
- abapGit
Connections
Producing a web user interface from ABAP code
Office add-in running an abap2UI5 app in Excel's task pane
UI5 apps written as one ABAP class, rendered by a generic shell
In-browser ABAP editor beside the abap2UI5 app it builds
UI5 apps written as one ABAP class, rendered by a generic shell
Git client written in ABAP that runs inside the system
Template repository for own UI5 artefacts served to abap2UI5
UI5 apps written as one ABAP class, rendered by a generic shell
Download
README
quoted from abap2UI5/frontend under MIT, read
abap2UI5 frontend
This repository contains an abap2UI5 frontend artefacts service. For more information on installation, check out the installation guide.
This repository is generated — it does not take manual pull requests
It is not where the frontend is written, it is where the frontend is published. Every branch here is built in abap2UI5 and pushed in — first as
result/<branch>folders into one commit onmain, then fanned out by thedeliverworkflow — so frontend changes belong there and bug reports belong in its issues. Theguardcheck fails every pull request opened here by default; maintaining this repository's own docs is the one exception, unlocked by a maintainer with themaintenancelabel. Full rationale: CONTRIBUTING.md.abap2UI5/abap2UI5 abap2UI5/frontend frontend_deploy deliver app/webapp/ ──▶ tools/out/ ──────▶ main ──────────▶ cloud (the webapp) (each branch result/<branch> cloud_v2 + frontend/ built at deploy (all six trees, standard abap, embed time, git-ignored, one commit per standard_v2 never committed) change) cloud_new standard_new (each: main + one commit) standard_<name> is built on demand and pushed straight onto its branch
Branch
Every branch is generated in abap2UI5 — the webapp lives in app/webapp there, everything else a branch is built from in frontend/ — and built there by tools/build-branches.mjs into the git-ignored tools/out/, never committed on that side. Its frontend_deploy workflow writes the six stamped trees as result/<branch> folders into one commit on main here, and the deliver workflow turns each folder into its branch: one commit on top of main, carrying the folder's content and nothing else. So every branch is always exactly one commit ahead of main, main's history shows every change a branch ever received, and what arrives on a branch is what a pull request over there reviewed. Pull the one that matches your system:
| Name | System | UI5 | Built by |
|---|---|---|---|
| cloud | S/4 Public Cloud, BTP ABAP Environment | classic | npm run frontend:cloud |
| cloud_v2 | S/4 Public Cloud, BTP ABAP Environment | legacy-free (UI5 2.x) | npm run frontend:cloud_v2 |
| standard | S/4 Private Cloud, S/4 On-Premise, R/3 NetWeaver >750 | classic | npm run frontend:standard |
| standard_v2 | S/4 Private Cloud, S/4 On-Premise | legacy-free (UI5 2.x) | npm run frontend:standard_v2 |
| cloud_new | S/4 Public Cloud, BTP ABAP Environment | embed control | npm run frontend:cloud_new |
| standard_new | S/4 Private Cloud, S/4 On-Premise, R/3 NetWeaver >750 | embed control | npm run frontend:standard_new |
The _new branches carry no copy of the abap2UI5 frontend: their app is one view with one z2ui5.embed.Container, a custom control that loads the frontend from the backend it runs against (?z2ui5-bundle) — the frontend always has the version of the backend it talks to, and an abap2UI5 update needs no frontend pull any more. Same objects, names, endpoints and launchpad settings as cloud and standard - a system switches between the branches by pulling another one, and launchpad target mappings and external links keep working (checked on every build by tools/check-identity.mjs); they need an abap2UI5 newer than 1.146.0. The app lives in frontend/embed of abap2UI5, the control is developed in abap2UI5/embed-control and published as @abap2ui5/embed-control, and each of the two branches has a README of its own.
main carries this repository's own docs plus the machine-written result/ trees — it is not a source either: a hand edit to result/ is overwritten by the next delivery.
Where to change what
Nothing in this repository is written by hand any more. A change made to a generated branch or to result/ is discarded on the next delivery, without a trace in the history:
| Content | Owned by |
|---|---|
result/ on main | abap2UI5 — its frontend_deploy workflow commits the six finished trees, one commit per content change |
every branch (cloud, cloud_v2, standard, standard_v2, cloud_new, standard_new) | the deliver workflow here — each branch is main plus one commit carrying its result/<branch> content |
standard_<name> | abap2UI5 — built on demand by a frontend_deploy dispatch and pushed straight onto the branch |
the app of cloud_new and standard_new | abap2UI5, frontend/embed — the control it holds is abap2UI5/embed-control's, pinned as @abap2ui5/embed-control |
this repository's docs (main) | here, as a maintenance pull request |
So a frontend change belongs in abap2UI5: edit app/webapp there and run npm run app2abap to regenerate the embedded ABAP resources under src/01/03. No delivery tree is committed with it: frontend_check builds all six branches from the pull request into the git-ignored tools/out/ and checks the BSP packaging against the webapp being changed, and frontend_deploy runs the same build on main, stamps the trees and delivers them into result/ on main here, from where deliver fans them out into the branches. (npm run frontend:build is that build on your machine, npm run frontend:verify compares it with what is published here.)
The _new branches take the other route to the same place. Nothing of app/webapp is generated into them: their app in frontend/embed is one view with one z2ui5.embed.Container, and the control fetches the abap2UI5 frontend from the backend at runtime — so a change to the frontend reaches a system on these branches with the backend, without a delivery here. What is delivered is the app itself, the control at the version pinned in frontend/embed/package.json and in the root package.json of abap2UI5 (both, or the build fails), and the ABAP artefacts. The control is developed in abap2UI5/embed-control and published as @abap2ui5/embed-control: a limitation of the control is fixed there, one of the frontend in app/webapp, and neither is worked around in the app.
Because the overwrite is not loud — the change is merged, works, and vanishes on some later unrelated run — the convention is enforced rather than trusted: the guard workflow fails every pull request opened here, and a change to this repository's own docs is unlocked by a maintainer applying the maintenance label.
Renaming
Need the BSP under a different name (e.g. a second copy in the same system)? Run the frontend_deploy workflow in abap2UI5 with a branch name of the form standard_<name> — plain (ZMYUI5) or in a registered namespace (/ABAPGIT/ → BSP /ABAPGIT/UI5, handler /ABAPGIT/CL_LP_HANDLER) — it generates and pushes a branch standard_<name> / standard_v2_<name> with the whole deployment identity (BSP, SICF nodes, handler class) renamed. For a backend that was itself renamed with the build-rename workflow, append __<name> (standard_#abap2ui5#__#abap2ui5#): the handler then calls that backend's cl_http_handler. Details in tools/bsp_rename.
Sibling BSPs
app/webapp/manifest.json reserves two resourceRoots that point next to this BSP, so a system can add frontend artefacts without a change here:
| resourceRoot | Sibling BSP | Built from |
|---|---|---|
z2ui5_cci | Z2UI5_CCI | abap2UI5-addons/custom-controls — community custom controls |
z2ui5_ccc | Z2UI5_CCC | abap2UI5-addons/custom-controls-customer — a customer's own reuse library, icon font or CSS |
Neither BSP has to be installed: the browser requests nothing from a resourceRoot until a view names the namespace. Both entries come from abap2UI5 app/webapp — see "Where to change what" above.
Dependencies
- abap2UI5 — the frontend artefacts pair with the abap2UI5 framework installed in the backend
Issues
For bug reports or feature requests, please open an issue in the abap2UI5 repository.
History
Others providing
Compare all 17 on the UI written in ABAP page →- abap2UI5-localabap2UI5-localThe whole abap2UI5 framework folded into the local classes of one HTTP handler, so an app runs without the framework installed as a package.community org, abapabap2UI5 folded into the local classes of one HTTP handler
- abap2UI5abap2UI5One ABAP class implementing z2ui5_if_app is the whole app: the browser loads a generic UI5 shell once, and every interaction after that is an HTTP roundtrip back into ABAP.community org, abapUI5 apps written as one ABAP class, rendered by a generic shell
- abap-cloud-guiabap-cloud-guiA report-style programming model for abap2UI5: one class produces a selection screen with a WRITE list or an ALV grid, running as a UI5 app on ABAP Cloud as well as on NetWeaver 7.02.independent, abapReport-style programming model for abap2UI5 on ABAP Cloud
- custom-controlscustom-controlsThirteen custom controls for abap2UI5, a signature pad and a scanner that reads several barcodes at once among them, each one an ABAP builder class with a single render( ) method and all of them shipped in a BSP of their own.community org, abapThirteen custom UI5 controls for abap2UI5 apps
- http-connectorhttp-connectorAn add-on that makes the abap2UI5 apps of one ABAP system reachable through another: a thin ICF handler on the consumer system forwards every roundtrip to the source system through an SM59 destination.community org, abapForwards abap2UI5 roundtrips to another system over HTTP
- layout-managementlayout-managementAn abap2UI5 addon that renders an internal table or a structure as a UI5 table or form with a settings popup, where the user lays it out and saves the result as a layout variant.independent, abapTable and form layouts with saved variants for abap2UI5
- abap2UI5 for Excelabap2UI5 for ExcelAn Office add-in that runs an abap2UI5 app in Excel's task pane, where the app reads and writes the workbook through the z2ui5.cc.ExcelBridge control.community org, abapOffice add-in running an abap2UI5 app in Excel's task pane
- abap2UI5-addons/popupsabap2UI5-addons/popupsReady-made dialogs for an abap2UI5 app: confirm, inform, select from a list, file up- and download, table, text edit, PDF, HTML, messages, range, value help and search help, each opened with one factory( ) call.community org, abapReady-made dialogs for abap2UI5 apps
- rap-extrap-extFloorplan classes that read a CDS entity's UI annotations at runtime and render a list report, worklist, tree, object page, overview page, value help or action dialog as an abap2UI5 app.community org, abapFloorplans rendered from CDS UI annotations as abap2UI5 apps
- selection-screenselection-screenSelect-options with saved variants for an abap2UI5 app, built from a database table name or from an internal table the app passes in.independent, abapSelect-options with saved variants for abap2UI5 apps
- abap2UI5 frontend-webcomponentabap2UI5 frontend-webcomponentAn alternative abap2UI5 frontend: one ES module registering <abap2ui5-app>, which renders the views an unchanged abap2UI5 app class sends with UI5 Web Components and no UI5 core.community org, abapabap2UI5 frontend rendering with UI5 Web Components
- abap2UI5 Layout Editorabap2UI5 Layout EditorA browser editor that lays out a UI5 view by drag and drop and writes it out as one abap2UI5 app class, pulled into the system with abapGit.community org, abapDrag-and-drop UI5 view editor that writes an abap2UI5 app class
- abap2UI5 protocolabap2UI5 protocolThe abap2UI5 roundtrip written down: a versioned specification of the wire between frontends and backends, JSON Schemas for its messages, and two conformance suites that test either side.community org, abapVersioned specification of the abap2UI5 roundtrip protocol
- ZFPM_TOOLSZFPM_TOOLSA report that shows the development objects of an FPM hierarchy in one view and edits, copies, deletes, imports and exports the hierarchy as a whole rather than one object at a time.independent, abapEdits, copies and transports a whole FPM hierarchy at once
- ZWD_CALENDAR_VHZWD_CALENDAR_VHA value help for date fields in Web Dynpro ABAP screens that shows a calendar view, so the user picks a day from it instead of typing the date.independent, abapWeb Dynpro ABAP calendar value help for date fields
- abap_mustacheabap_mustacheA Mustache template engine for ABAP, rendering logic-less templates into HTML or any other text from a structure or table of any type, with partials and a separate Steampunk-compatible branch.independent, abapMustache template engine for ABAP
Details
Sources
Sources are graph entities: the same page may back several entries, and an unreachable source flags every row that rests on it.
Compatibility and provenance
Contributors
History in the atlas
- First seen.
For your agent
- Ref
artifact:abap2ui5-frontend- JSON
- /artifacts/abap2ui5-frontend.json
- MCP
- Connecting an agent