abap2UI5 Playground

abap2UI5 Playground

Write abap2UI5 apps in the browser. ABAP on the left, the running app on the right, and nothing in between but the browser — no server, no SAP system, no backend of any kind.

First time here? The playground opens on a first lesson, with a strip of four first steps over the editor's last lines: change the code and press Run, turn on Auto, edit the view in the View tab, browse the samples. ✕ or Escape closes it for good in this browser. While the app in the editor is one of the learning path's "Start here" lessons (Basics I–VII), Lesson n of m over the file strip steps to the lesson before or after. Neither appears on a link somebody sent you, an embed or the AI pages.

How it works

The abaplint transpiler translates ABAP to JavaScript. abap2UI5 already relies on it — its CI transpiles the whole framework and runs the ABAP unit tests under Node. The playground takes that pipeline and moves the last step into the browser.

                     ┌──────────────────────── the page ────────────────────────┐
                     │                                                          │
  build time         │   Monaco + abaplint            the ABAP runtime          │
  ──────────         │   ┌─────────────────┐          ┌──────────────────┐      │
  abap2UI5 sources ──┼──▶│ registry:       │          │ abap2UI5,        │      │
  (910 files)        │   │ the real        │  Run     │ transpiled at    │      │
                     │   │ framework       │──ABAP───▶│ build time       │      │
  abap2UI5 src ──────┼──▶│ + your classes  │  → JS    │ + your classes   │      │
  downported,        │   └─────────────────┘          └────────┬─────────┘      │
  transpiled,        │                                         │ roundtrip      │
  bundled            │   ┌─────────────────────────────────────▼─────────┐      │
                     │   │ iframe: the abap2UI5 UI5 frontend             │      │
  OpenUI5 ───────────┼──▶│ window.fetch redirected to the runtime above  │      │
  built from npm     │   └───────────────────────────────────────────────┘      │
                     └──────────────────────────────────────────────────────────┘

• Build time. The abap2UI5 sources are downported to 702-compatible syntax (abaplint --fix), transpiled, and bundled into one static module along with the open-abap standard library. The UI5 frontend is built against a pinned OpenUI5, so the site carries its own UI5 rather than linking a CDN.
• Page load. That bundle boots the ABAP runtime, and an in-memory SQLite (sql.js, compiled to WebAssembly) takes the place of the database abap2UI5 keeps its drafts in. In parallel, abaplint parses the real framework sources so the editor can check your classes against them.
• Editing. Monaco — the editor from VS Code — with abaplint behind it: diagnostics against the actual framework, hover, go to definition, rename, references and quick fixes. Format ({ } in the bar, and Shift+Alt+F, which does the same) is abaplint's pretty printer with its layout fixes in front of it — indentation and keyword case, and also the tab, the trailing space, the double space after a keyword, an = or a bracket (padding in front of a token is kept, as alignment), the space before the full stop and the two statements sharing a line — over every file that is open, as one edit that Ctrl+Z takes back. It never reflows a builder chain and never changes what the code does. Under the editor, a resizable panel with the view your chain builds, every problem, an outline of the class, the unit tests, the conversation between the app and the ABAP, the app's State after each roundtrip (its attributes, with what changed marked — the debugger's variables view for a program that runs a roundtrip at a time), the Console (what the app WRITEs, per roundtrip), the log, and the configuration of each checker — editable, so "why is it not warning here?" has an answer you can try rather than only read.
• A second opinion. The abap2UI5 linter runs beside abaplint and answers a different question: abaplint says whether the ABAP compiles, the linter reconstructs the view your builder chain produces and says whether that works on UI5 1.71 — a control or property that release does not have, an icon that is in no icon font. Those compile, and at run time they render nothing and log nothing.
• Editing the view instead of the chain. The View tab shows the XML that reconstruction produces, coloured; Edit turns it around. Change the XML — move a control, add a property, insert a Label — press Save, and the builder chain is written again to build it, in the layout the abap2UI5 repositories hold their chains in. An attribute you leave alone keeps the ABAP that produced it, so a client->_bind( … ) stays a bind rather than freezing into the string it happened to render as — and so does the code around it: change one word and one word changes, in the shape the method was written in, rather than the whole chain coming back reformatted. It is the shortest way there is to learn the builder: change the view, read the ABAP that changed with it. What it cannot rewrite — a view filled from a LOOP, a control name held in a variable — it says instead of guessing, and the ABAP editor greys out and stops taking typing for as long as the view is the one being typed into.
• Run. Only the classes in the editor are compiled, in about 20 ms, and registered with the running runtime. Auto beside it presses Run for you, shortly after you stop typing: while it is on, Run itself is inactive and every edit reaches the app on its own. It is off to begin with, because a run is a fresh database and a reloaded app frame — which is exactly what you do not want halfway through filling in a form, and exactly what you do want while a view is taking shape.
• Rendering. The abap2UI5 frontend runs in an iframe and talks to its backend over a plain fetch POST, so the playground replaces window.fetch for that one request with a message to the parent page, which hands it to the framework and posts the answer back. The frame and the page exchange messages and nothing else. From the framework's point of view nothing changed.

Roughly 3 MB travels to a visitor, compressed: the page bundle, the transpiled framework, the ABAP corpus and SQLite. UI5 loads its libraries on demand on top of that.

What it can and cannot do

It runs real abap2UI5. Not a subset and not a simulation: the framework in the page is the framework from the repository, at a pinned commit, and the roundtrip it answers is the one a real system answers. Modern ABAP works as written — inline declarations, VALUE #( FOR … ), COND #, string templates, table expressions.

Where it stops:

• A few classes, not a package. The playground holds several ABAP files, named as abapGit names them, and the first one is the app - the playground starts the class it declares. What it does not have is most of what else a package brings: no message classes, no CDS.
• Tables of your own, but nobody else's. A table is two files beside the classes: <name>.tabl.xml, the abapGit TABL definition, and optionally <name>.tabu.json, the rows it starts with — a JSON array of objects keyed by field name (either case), at most 1000. SELECT, INSERT, UPDATE and DELETE work against it. + table in the file strip adds a starter pair, zproducts with five rows. The table is created afresh with its rows at every Run, and nothing an app writes outlives the Run. A field typed by a data element needs that data element to exist in the framework corpus; a MANDT the rows leave out is the current client; a table may not reuse a name the framework or open-abap already has. ?src= still opens ABAP only; a gist carries both files, and Download for abapGit puts the table in src/ and its rows in data/, abapGit's own data layout.
• No business tables, no RFC, no files. The database holds the framework's own tables and yours. SELECT from a business table has nothing to select from, and nothing can reach outside the browser.
• Only what the transpiler implements. It covers a lot, and abap2UI5's whole CI depends on it, but it is not an ABAP kernel. Anything it cannot compile is reported in the output panel rather than failing silently.
• Only the UI5 libraries that were built in. sap.m, sap.f, sap.ui.core, sap.ui.layout, sap.ui.table, sap.ui.unified, sap.tnt, sap.uxap, sap.ui.integration, sap.ui.codeeditor. A control from anywhere else will not load — see UI5_LIBRARIES in src/shell/ui5-libraries.mjs, the one list the UI5 build, the examples browser and the sample catalogue all read.
• State lives in the tab. Reloading the page starts over, and so does pressing Run — your tables included. Your code is kept in local storage; the app's data is not.

Both halves follow your system's light or dark setting — the editor through Monaco, the app through UI5's Horizon themes. Changing it while an app is running recolours it in place rather than restarting it.

Which problems it reports

abaplint runs with a deliberately small rule set: the ones that answer would this work, not the ones that answer is this the house style. A playground that underlines a missing pragma teaches nothing.

check_syntax, parser_error, implement_methods, method_implemented_twice, global_class, begin_end_names, superclass_final, unknown_types — checked against release v750, the one abap2UI5 lints itself against. The list lives in src/editor/registry.mjs.

definitions_top is the rule that had to come off that list, and it is worth naming: abap2UI5 enables it because the framework is downported to 702 before it is transpiled, and nothing here downports what is in the editor. It was rejecting FIELD-SYMBOLS after a CREATE DATA — ABAP that compiles on every system this playground is about — and an abaplint error stops Run, so the reader was told to fix code that had nothing wrong with it.

The abap2UI5 linter runs its own rules on top, against UI5 1.71 — the floor abap2UI5 holds its own shipped apps to, and therefore the floor an example copied out of the playground has to clear. UI5 in the bar, after Auto ("Check against UI5" in the ⋯ menu on a phone), moves that floor: 1.71, 1.84, 1.96, 1.108, 1.120 or the latest this site carries — "my system runs 1.84, what will not render there?". It is the same setting as the abap2UI5 lint tab's ui5, kept between visits the same way.

The two are kept apart on purpose, in the list and in what they block: an abaplint error means the ABAP does not compile, so Run stops and says so. An abap2UI5 finding means the app runs and is wrong somewhere — and the fastest way to understand one is to look at the app it produced, so Run goes ahead.

A missing full stop is said as one. abaplint reports a statement it cannot parse as "Statement does not exist in the configured ABAP version (or a parser error)", and the commonest reason is a full stop that is not there — two lines read as one statement. Where the shape says so, the Problems row asks whether a full stop is missing and sits on the line that wants it.

Fix them appears over the list when something is repairable and says what — how many errors, warnings and hints it can repair, and which errors it leaves — abaplint's own fixes and the linter's, applied together. It goes in as one edit per file, so Ctrl+Z takes the whole rewrite back rather than unpicking it fix by fix. Nothing that has no correct answer is guessed at: an icon that does not exist stays reported rather than invented.

Both lists are only a default. The abaplint and abap2UI5 lint tabs hold the live configuration: add any of abaplint's 188 rules, change the ABAP release the syntax check holds you to, or lower the UI5 floor the view is checked against to find a control an older system would not render. Apply reports how many problems there are now, so a rule can be tried rather than argued about, and what you change is still there the next time you open the page — Reset puts it back to the curated list of the day.

Build an app by describing it

The AI Studio has a page of its own, /playground/ai/

• the AI Studio button beside Samples, and the menu's Tools section on every page of this site. It starts on a minimal class: z2ui5_if_app implemented, main still empty. The chat runs down the left, and the stage beside it shows the running app in a window of its own, the code, or both side by side (Preview, Code, Split in the studio's bar; a phone takes them in turns, the chat first). Every run that starts the app is a card in the conversation that brings the app forward; ⛶ makes it the browser's full screen. Describe the app you want — "a table of flights with a search field" — and Claude writes it as an abap2UI5 class into the editor, presses Run, reads what the two checkers and the app said, fixes it, and runs it again until it is clean. You watch the code arrive in the editor and the app appear on the right while you talk; ask for changes until it fits, then Download for abapGit takes the class home as a repository you import with abapGit.

• Your own key, and no server. The first message asks for an Anthropic API key. It is held in the page's memory for the visit, never stored — the playground runs ABAP from any link, and stored it would be readable by that code — and sent to api.anthropic.com and nowhere else — or, with an OpenAI-compatible server picked in the key form (OpenAI, Ollama, LM Studio), to that server, which the form names; there is still nothing behind this page. Usage is billed to that key; the chat's header counts the tokens. A key that is not tied to a workspace (the API answers "This API key is not scoped to a workspace") also needs the workspace ID (wrkspc_…, in the Console under Settings → Workspaces), which the key form takes as an optional second field.

• The app cannot reach your key. On this page the app runs in a frame on an origin of its own (a sandbox), and talks to the page by message only: a script in an app's view — whoever wrote it, Claude included — cannot read the key form, the page or its storage. The ABAP runs in a worker that has no page and no storage to read either. The cost is that the app frame here loads UI5 from the network every time and does not work offline.

• The model uses the playground the way you do. It has no compiler of its own: it writes files into the editor (Ctrl+Z takes them back), presses the same Run, and is told what you would see — the abaplint errors, the abap2UI5 linter's findings against UI5 1.71, the unit tests, the view the app rendered and the line a dump was raised at. Switch the chat off and the code it wrote is in the editor, ready to edit by hand; switch it on again and the model is told what changed.

• It knows abap2UI5 from the source. Its instructions are abap2UI5's own guide to building apps, at the same commit as the framework this page runs, and it can search the sample catalogue and read a sample's code before it writes its own.

• Files in the chat. 📎, a drop anywhere on the page or a paste adds a specification (PDF, Word), a screenshot or mockup of the screen you want, an Excel sheet whose rows become the app's data, or a text file — the same formats and limits as in the AI Pilot below, read in your browser.

• It tries what it built. Once a run is clean, the model can type into the app's fields and press its buttons - the Pilot's eyes and hands, on the same frame - and read the toast or the message box the app answered with, so what it hands you is an app that worked once, not code that compiled.

• Every step can be taken back, and the last message changed. A step that changed the files offers them back under its answer; ✎ on your latest message takes the exchange out and puts the text back to send again. Export writes the conversation as a markdown file, and the files stay in this browser - the welcome offers the last build back.

• The limits are the playground's. No tables of your own, no RFC, only the UI5 libraries built in (see What it can and cannot do) — the model is told so, and fills internal tables where a real app would SELECT.

The select in the chat's header picks the model and how long it thinks: Balanced (Opus 5.5, the default), Thorough (Opus 5.5, thinking longer) or Fast (Sonnet 5.5, which answers soonest) — it applies from the next message. After every change the page runs the app by itself and hands the model the report, so no turn is spent asking for a run, and while a turn is under way the chat shows the model's short notes and counts the lines of the class it is writing. A request a safety classifier declines is answered by the fallback model the API picks rather than dropped. The SDK and the guide are a chunk of their own (~70 KB compressed), downloaded only by somebody who sends a message.

Let Claude operate an app

Still being built, and not linked from the playground either: the AI Pilot has a page of its own, /playground/pilot/. Where the AI Studio builds an app, the Pilot uses one: the app runs on the stage, the chat stands beside it, and you say what you want done — "greet Carol", "open the value help sample and pick the third colour". Claude reads the screen, types into the fields and presses the buttons, in the app on your screen: you watch the values arrive, the popup open, the message box come up. Take the controls yourself whenever you like — Claude is told what you did and carries on from there.

• What Claude sees (the button in the bar) shows the screen the way the model reads it: the agent snapshot — fields with their values, the actions it can fire, the tables, what the app said. Nothing else: no screenshot, no CSS selector.
• The same protocol as everywhere else. The client that turns "fill these fields, fire that event" into the request the browser would send is abap2UI5/mcp-server's own, vendored unchanged — the one the VS Code extension runs against an SAP system and cap2UI5 runs inside CAP. Its requests are sent by the app frame, so the frontend renders every answer with its own code.
• Strict. An event that is not on the screen, a field that is not editable, a value outside a dropdown's choices are refused with what is possible, and nothing is sent.
• Any sample. It opens on Basics II; Change app opens the samples browser, and Claude can look an app up in the catalogue and open it itself. A shared link or ?src= opens your own class: /playground/pilot/?src=<raw url> - after you said so: the app's code cannot reach your key, but the app is what Claude reads and acts on, and an app written to mislead can steer what Claude does in this chat.
• Several apps at once. Up to four, one tab each over the stage — + App opens one beside the others, and so does Claude when a task spans two apps ("look the colour up in the value help app and greet it in the first"). They run in one runtime on one database, so opening an app keeps the others as they are; Restart starts all of them again on a fresh database.
• Files in the chat. 📎, a drop on the chat or a paste adds files to the next message — up to five, 10 MB each: a PDF and images go to the model as they are, an Excel sheet (.xlsx) as CSV with its dates as dates, a Word document (.docx) as its text with its tables as rows, a PowerPoint deck (.pptx) as its slides' text, and text files (CSV, JSON, XML, …) as text — "enter every order in this sheet". The Office files are read in your browser; the old binary formats (.xls, .doc) are refused with what to save them as.
• Your own key, and no server — exactly as in the AI Studio: held in memory for the visit, sent to api.anthropic.com and nowhere else, and out of reach of the apps' code — every app frame on this page, each tab's included, is on an origin of its own and talks to the page by message only.

The sample catalogue

https://abap2ui5.github.io/playground/samples/ — every abap2UI5 sample in one searchable page: the learning path of abap2UI5/samples, the UI5 demo kit ports of abap2UI5/samples-controls, and the OData/RAP/launchpad samples of abap2UI5/samples-stack.

It answers two questions the repositories' own catalogues cannot:

"which samples use sap.m.Table at all?" — not the one filed under it, but every view that actually builds one "my system runs UI5 1.84 — which of these will render on it?"

Both come out of the abap2UI5 linter, which each repository runs over its own classes and commits the answer to as catalogue-derived.json; this site joins those onto the catalogue.json beside them and builds one index at deploy time. The filters live in the URL, so a search is a link you can send: ?q=table&lib=sap.ui.table&rel=1.84.

A row is a link to that sample's page, and that is all it is: what a sample builds, what it needs, the ABAP itself, and a box that runs the sample in that page are all on the page it opens — ▶ Run it here under its title starts it. A title's (A) and (C) markers are shown as frontend action and custom control badges, which a search finds. Most samples run in your browser with nothing installed. What cannot — a stack sample, which needs a real system; a port whose library only SAPUI5 has — is listed all the same, says what it needs, and opens for reading instead: a sample you cannot find is worse than one you cannot run. Run it from its page and the playground's bar offers Back to the catalogue, in the same tab.

Every sample has a page of its own — samples/<class>/, a static document with the sample's description, the class, every control it builds, the release it needs, what it needs when it cannot run here, the sample running — press the demo box and the app mounts in the page, on its own, without the editor over it —, the whole class printed and syntax-coloured, every line of it with an address — #L42 highlights a line, #L42-L58 a passage, and Copy link hands the result over —, and the links out: the class on GitHub, SAP's own sample running in the demo kit for a port of one, the whole playground, back to the search. The catalogue itself is one URL that JavaScript fills in, which is right for searching and useless for being found: there was no address for "the abap2UI5 port of sap.m.Wizard" and so nothing a search engine could return. Now there is one for each of them, listed in sitemap.xml and reachable from the full list.

This replaced three separate GitHub Pages sites, one per sample repository.

The examples browser

Samples in the bar is the same list without leaving the editor, and it takes the screen while it is open: a full-size window over the playground, the filters down its side, the rows in as many columns as fit. Your drafts is one folded line at the top, with how many there are (it stays open or closed as you left it, and a search that matches a draft opens it); under it everything the catalogue holds — "N of M samples", the same count as the catalogue page — searched by several words in any order, over titles, summaries, class names, badges and the controls a sample builds, and narrowed by the same facets the catalogue page has: the control it uses, the library, the release your system runs, plus the repositories, "Only samples that run in this browser", "Leave out samples that need SAPUI5" and "Include samples that need a UI5 newer than 1.71". Every row says what it is, what group it belongs to, what release it needs and — where it cannot run here — what it needs instead, and links to its ABAP on GitHub and to its documentation page. A sample the page carries is listed once, as its row of abap2UI5/samples, and opens the copy the page carries; "In the page" lists only a carried sample the index does not have. A chosen entry opens through the same path a ?src= link takes — the raw URL of its class, fetched, checked and run — so it arrives with the Source link back to where it lives.

It reads the same index the catalogue page does, from this site rather than from GitHub, and nothing is fetched until the button is clicked. Where the index cannot be had, the browser quietly lists the samples in the page and your drafts alone. Everything offered is judged the way typed code is judged — a catalogued sample the transpiler cannot compile says so in the Problems list, which is the designed behaviour.

Linking a playground

Unit tests. A file named <class>.clas.testclasses.abap beside a class — the + in the file strip offers one, with a skeleton that passes — holds its local test classes, exactly as abapGit keeps them. Run runs them first, through the runner open-abap ships, and starts the app after: a failing test is listed in the Tests tab with what was expected and what was there, its row goes to the assertion, and the status line says how many failed.

Drafts. The playground keeps whatever was last in the editor on its own. Opening a sample over it never loses it: the status line says which way back there is — one Undo away when the sample went in under the same file name, and otherwise kept in Samples, under Your drafts, under the name it was saved as or as "Before the last pick" (only where the browser refuses to store it does the line fall back to comes back if you reload). For more than one piece of work, the samples browser has Your drafts at the top: name what is open, save it, and it is listed there — in this browser — to open or delete another day.

Compare and Reset to original. Code that was opened from something — a sample, a share link, ?src=, a gist, a saved draft — has an original, and ± beside Source shows your changes against it, file by file, in a diff; ⟲ puts every file back as it was opened, as one edit per file that Ctrl+Z takes back (a file you added goes to Your drafts). Where there is nothing to compare with — the last session restored, or what an AI wrote — they say so instead.

Share puts every open file in the URL fragment, deflated: a 2500-character class becomes a link of about 700 characters. Being a fragment, it never leaves the browser — it is not sent to the server and does not appear in any log. The link is copied first; the dialog that opens then has the other ways out: the block that embeds this demo in a documentation page (the loader with the class inline, or the playground framed when there are several files), the markdown fence a docs page prints an example in, and Download for abapGit — a zip laid out as a repository rather than as a bag of files: the sources and their metadata under src/, the .abapgit.xml that says so (the shape app-template carries), and a README naming the app, how to start it and the link this code came from. Import it offline with abapGit, or push it as it stands. Gist writes the open files to a secret GitHub gist with your token (held for the visit, never stored) and hands back a ?gist=<id> link; once code from a link has run in the page, it asks you to tick that you know before it takes a token. Open in Layout Editor hands the app class to the abap2UI5 layout editor, to design its view by drag and drop and export the class back: a class still exactly as it came from GitHub opens there by its address; anything else is copied to your clipboard to paste into Open ABAP class there, and rides in the link as well, for a layout editor that reads it.

Light or dark. The page follows the system until the switch in the menu behind the bar's last button says otherwise — the same menu the sample catalogue and the documentation carry, after LinkedIn and GitHub, with the project's tools and repositories under the switch. A choice is kept between visits; a choice that agrees with the system is forgotten rather than stored, so a page switched back follows the system again from then on. The button reaches the editor and the running app as well, without restarting it.

Installable. The page carries a web app manifest, so a browser that supports it offers to install the playground; opened from a home screen it runs with no network at all, on the build the last online visit left in the service worker's cache — the two documents included, and whatever UI5 modules the apps run so far have loaded. The ABAP runs in the tab either way, so there is no server to be away from.

Full screen opens the app on its own in a new tab — the whole window for the app, nothing around it: no editor, and no bar over it either. It is the same URL Share writes plus ?view=full, so the new tab is a second playground rather than a window onto this one: it compiles the code it was handed and runs it against a runtime of its own. What happens back in the first tab — another Run, an edit, closing it — leaves it alone.

?src= opens ABAP that lives somewhere else, which is what a documentation page links when it wants to show its example running rather than only printed:

?src=https://raw.githubusercontent.com/abap2UI5/samples/main/src/z2ui5_cl_smp_app_493.clas.abap

A github.com/…/blob/… page URL works as well — it is read as the raw file behind it. Several src parameters open several files; the first is the app — and the classes that app needs are looked for beside it and opened too, so a link to an app that calls another app opens both. Only siblings in the same directory, only from the hosts above, at most six files two levels deep; a name that is not there is skipped in silence, because most of them are in the framework corpus rather than in the repository. Code opened this way carries a Source link in the bar (its GitHub page — the bar's GitHub mark, at the far end, is the framework's repository), following whichever file is open — the raw URL the playground was given translated back into the page a human would want, with the repository and the history around it. Sources are limited to this site and GitHub's raw hosts — the playground fetches on behalf of whoever opened the link, and should not be a general-purpose reader for arbitrary URLs.

?embed=1 drops the brand, the examples browser, the share button and the right-hand end of the bar, leaving the editor, Run and the app — for embedding in a documentation page. An embedded playground never touches the stored draft, so it cannot overwrite what a reader has open in a normal one, and follows its reader's system theme rather than a choice made in some other tab. ?view=app drops the editor too, for a paragraph about what an app does rather than how it is written; the ABAP still compiles and runs, it is simply not on screen. ?view=full is the same view under the name Full screen opens it by. Neither shows the bar — the app and nothing else — because Run, the source and undo are all one click away in "Open in the playground" beside the frame, and a bar over a demo is this site's furniture in somebody else's page. It comes back if something goes wrong, because the status line it carries is the only channel either view has left.

Two more parameters work only in an embedded playground: ?readonly=1 takes the typing away — and Format, Undo, Redo, Fix them and the View tab's Edit with it — while Run still runs, and ?lines=12-18,25 marks those lines of the app's file and scrolls to the first (L42-L58 reads the same, the shape a sample page's line links have).

Live demos in a documentation page

embed/abap2ui5-embed.js turns an empty element into a running example:

<div class="abap2ui5-demo"
     data-src="https://raw.githubusercontent.com/.../z2ui5_cl_demo.clas.abap"></div>
<script src="https://abap2ui5.github.io/playground/embed/abap2ui5-embed.js"></script>

data-src takes one URL or several (the first is the app), data-code carries ABAP that lives only in that page, data-view="app" hides the editor, data-height sets the starting height and data-label the button text. data-readonly shows an example to read and run but not to change, data-lines="12-18,25" marks and scrolls to those lines, and data-reset shows a Reset example button under the demo once the reader has edited it, which puts the page's code back (as an edit Ctrl+Z takes back) and runs it. For a documentation framework that swaps pages without reloading, call window.abap2ui5Embed.setUp() after each navigation.

Inline code keeps the name the page gave it: the file it is put into is named after the class in it, the way abapGit names one, so data-code carries the example a manual prints under the name its reader is meant to create.

A page that draws its own button — because it wants one under a code block it already styles — asks the loader for the URL instead of writing the fragment itself:

const href = await window.abap2ui5Embed.url({ code, view: "app" });

url() takes readonly and lines as well.

That matters more than it looks: a fragment the playground cannot read is replaced by the sample the page opens on, with the status line and the Log saying so - so an encoder written by hand fails by showing the wrong code with a warning under it rather than by failing outright.

Nothing loads until the reader clicks. Each demo is a whole ABAP runtime plus an abaplint parse of nine hundred sources — a second or two of processor and a few hundred megabytes, per frame. Demos on one page share the browser cache, and after the first visit they share the playground's service worker cache as well, so the bytes are paid once and then not again; the parsing is not shared either way, and a page with ten autoloading examples would be the slowest thing in the manual. data-auto="1" overrides it where the page is about its one demo.

The app frame is served with UI5's frameOptions set to allow rather than the trusted abap2UI5 ships. trusted means "only in a frame whose top window is the same origin", and an embedded demo's top window is somebody else's manual: UI5 asks it for permission over postMessage, waits ten seconds for an answer no documentation site knows to give, and then hides everything it rendered — an app that is in the DOM, correct and invisible, under a status bar saying "running". What is unprotected is a demo compiled from code the embedding page supplied, with no session and nobody's credentials.

An embedded playground posts four kinds of message to the page that framed it — ready once it has something to show, status for each line its status bar shows, height for what an app-only demo wants to be, and edited ({ edited: true|false }, only when it changes) — and the loader turns the last into a bubbling abap2ui5-edited event on the demo's element (event.detail.edited), so a page can tell whether its example was changed. One message goes the other way: { source: "abap2ui5-embed", type: "reset" }, accepted only from the window that framed the playground, which is what data-reset's button sends. embed/ on the published site is a worked example of all of it, and is what the tests drive.

Development

npm ci
npm run build     # pins deps, builds the framework, builds UI5, assembles dist/
npm run serve     # serves dist/ on http://localhost:8080
npm test          # Playwright, against a freshly built dist/
npm run check     # build -> size budget -> tests, in the order that cannot go wrong
npm run lint      # ESLint; with typecheck and test:unit: no build, no browser
npm run typecheck # tsc over the modules that start with // @ts-check
npm run test:unit # node:test over the pure modules in tests/node/

PORT=8091 npm test moves the test server and the tests together, so two checkouts can test at once.

The first build takes a few minutes: the downport is three of them and the UI5 build one, and the two run at the same time because neither reads what the other writes. Both are cached by a hash of their inputs, so the second build is seconds.

The five steps — fetch the pins, build the framework, build UI5, build the sample catalogue, assemble the site — and what each one caches are described in docs/design/build-pipeline.md; tools/check-size.mjs is the budget for what a visitor downloads.

PG_DEBUG=1 builds the page and framework bundles unminified and with source maps; without it neither ships one.

src/runtime is the ABAP side of the page (run in a worker), src/editor is Monaco and abaplint (the registry in a worker of its own), src/shell is the page around them, src/catalogue is the sample catalogue at /samples/ (a second document with a bundle of its own), src/abap is the one class of ABAP the playground adds to the framework - the bridge into the request handler - and src/examples is ABAP served as static files so ?src= has something to point at; AGENTS.md lists every module. There are no samples here: the ones the page carries are named by class in src/editor/sample-list.mjs and come out of the pinned abap2UI5/samples at build time, so the playground holds no copy of a sample that can drift from the one upstream maintains.

Bumping abap2UI5 or OpenUI5

node tools/fetch-deps.mjs --print-latest   # what upstream has today
# edit the sha in tools/fetch-deps.mjs (or UI5_VERSION in src/shell/ui5-libraries.mjs)
npm run build && npm test

A weekly workflow (.github/workflows/upstream.yml) builds and tests against upstream HEAD without changing the pins, and opens an issue when that stops working — so a bump is a two-line commit rather than an investigation.

Deployment

.github/workflows/pages.yml builds and publishes dist/ to GitHub Pages on every push to main, after the tests pass — and nightly, which a static site would not otherwise need: the sample catalogue is built from files the three sample repositories commit, and those change when a sample is merged there, which is no reason for anything to be pushed here. .github/workflows/check.yml runs the same build and tests on every other branch and pull request.

Setup required once, by a repository admin: Settings → Pages → Source → "GitHub Actions". Until that is switched on the deploy job fails and the published page does not exist.

Where the work is written down

AGENTS.md is the short version for anyone changing the code: the layout, the commands, the CI gates, the rules and the deliberate limits. Each area's reasoning — with its measurements and what was tried and refused — is in docs/design/, and docs/design/build-traps.md holds the traps found while building it — the transpiler flag without which nothing links, the bundler option without which ABAP's own type system stops working, the caches that have to be dropped when a class is redefined. Read it before changing the build. The plan the playground was built from, phase by phase, is kept in docs/history/PLAYGROUND_PLAN.md.

License

MIT. abap2UI5, abaplint and OpenUI5 are the work of their respective authors and carry their own licenses.