SAP UI5

UI5 is an enterprise JavaScript/HTML5 framework: a large library of ready-made UI controls (tables, forms, charts), a Model-View-Controller structure, powerful data binding (especially to OData models), internationalisation, and the Fiori look and feel built in. Standard Fiori apps are UI5 apps; custom ones are built the same way.

Two names get used interchangeably and they are not the same thing. UI5 is the JavaScript framework: controls, data binding, routing, the lifecycle. Fiori is the design system and the set of applications built with it. So every Fiori app is a UI5 app, and a UI5 app that ignores the design guidelines is not a Fiori app. When somebody says they need a Fiori developer, they usually mean UI5 plus the conventions.

Where it runs is worth being clear about, because it changes how you debug. UI5 executes in the user's browser. The framework, the views and the controller code are all downloaded and run there, and the only thing the server does is answer data requests. So a problem is either in code running on the user's machine, which the browser developer tools show you completely, or in a service call, which the network tab shows you completely. There is no third place, and that makes UI5 problems unusually tractable once you stop guessing.

• Views & controllers (MVC): separate UI from logic.
• Models & binding: bind controls to data (OData/JSON models).
• Components & routing: structure multi-view apps.
• Fiori Elements: template-driven apps generated from CDS annotations, minimal hand-coding.

The concept everything else rests on is the model. A model holds data and the view binds to it, so the view does not fetch anything and does not know where the data came from. Change the model and the screen updates itself.

Three models cover almost all real work. The OData model talks to a back end service and is what a business application uses. The JSON model holds local data, which is what you use for anything the server does not own. And the resource model holds translated text, so no visible string is ever written into a view.

Alongside that sits MVC: the view declares the controls, the controller holds the behaviour, and the model holds the data. The rule that keeps a UI5 app maintainable is that views contain no logic and controllers contain no markup. It sounds obvious and it is the first thing that goes when somebody is in a hurry.

The third is the component and the manifest. The manifest declares the app's models, its routes, its data sources and its entry point, and the launchpad reads it to start the app. A great many "the app will not start" problems are a manifest that names a data source the system does not have.

Two hours with the tooling, and it makes binding stop being magic.

1. Generate a freestyle application from a template and point its data source at any activated OData service.
2. Put a list on the view and bind its items to an entity set. No code in the controller yet, and the list fills.
3. Open the network tab and find the request the binding issued. Note that the framework chose the page size and the fields.
4. Add a search field bound to a filter. Watch a new request go out with the filter in the query, not a new one on the client.
5. Now add a JSON model holding a single flag, bind a control's visibility to it, and change the flag in the controller. The screen updates with no code touching the control.
6. Move one visible string into the resource model and confirm it still renders.

Step four is the one that matters for performance: a filter that reaches the service is a different thing from a filter applied to what is already loaded, and the network tab is what tells you which one you built. See Fiori and OData.

Two build styles: Fiori Elements generates the app from an annotated OData/CDS model (fast, standard, low-code), while freestyle UI5 is fully hand-coded for bespoke UIs. Prefer Fiori Elements where it fits, it is less code and easier to maintain.

This is the main design decision on any new app, so it is worth stating what actually drives it.

Fiori Elements generates the whole application from the service metadata and its annotations. You write annotations, not screens. The upside is large: consistent behaviour, less code, accessibility and responsiveness handled, and future improvements to the floorplan arrive without you doing anything. The constraint is that you get the floorplan as designed. Pushing it into a shape it was not meant for produces more work than freestyle would have.

Freestyle gives you a blank view and full control, and everything the floorplan would have given you is now yours to build and to maintain.

The decision rule that holds up: if the app is a list of things and a detail view of one of them, which describes most business applications, use Elements. Use freestyle when the interaction is genuinely unusual and a standard floorplan would have to be fought.

The failure mode to avoid is starting with Elements, hitting one requirement the floorplan does not support, and adding extensions until the app is freestyle with extra steps. When you reach the second or third extension, that is the signal to reconsider rather than to keep going.

Modern UI5 development uses SAP Business Application Studio (or VS Code) with the UI5 tooling and templates, connecting to backend OData services. This is the modern front-end developer’s environment.

Where the code lives matters as much as which editor you use. UI5 applications are developed as projects with a defined structure and deployed either to the ABAP repository as BSP applications or to a cloud runtime. Deployment to the ABAP repository puts them under transport with everything else, which is what most on-premise landscapes do. The deployment target is a decision to make at the start, because it determines how the app reaches production and who is allowed to move it. See Fiori apps and tiles and catalogs.

Version note: the tooling has moved twice. Older material uses the Eclipse based tools, then the Web IDE, and current work uses SAP Business Application Studio or the open source UI5 tooling with a local editor. The framework concepts are unchanged across all of them, so an older tutorial is usually still correct about the code and wrong about where to type it.

• Freestyle coding where Fiori Elements would suffice.
• Ignoring data binding and manipulating the DOM directly.
• Heavy client logic that belongs in the backend/CDS.

• Logic in the view, markup in the controller. The first thing to go and the hardest to recover.
• Filtering on the client. The list looks right and the service returned everything.
• Hard coded strings. Cheap to avoid now, expensive to retrofit across an app.
• Extending Elements past the point where freestyle was the answer. See Fiori roles for what it takes to get the finished app in front of a user.

Building a list and a detail page is a couple of days, and knowing when to let the floorplan do it for you is the judgement the course builds.