SAP Development

• CDS views: model the data on HANA.
• RAP (ABAP RESTful Application Programming): define behaviour and expose OData services.
• OData: the service the app consumes.
• UI5 / Fiori Elements: the front-end, template-driven where possible.

One more piece belongs in that stack: the service binding, which is what turns a CDS model with a behaviour definition into an actual OData service of a chosen version. It is a small object and it is the step people miss, because the model can be complete and correct while nothing is exposed for an application to call.

Every Fiori development starts with this choice and getting it wrong is expensive in both directions.

Fiori Elements generates the application from the data model. You write a CDS view with annotations describing how fields should behave, and the framework produces a list report, an object page, an overview page or an analytical page from it. There is almost no UI code.

The gains are large and worth naming. The app follows the design guidelines automatically. It inherits new capabilities when the framework is updated. Personalisation, variant management, export and accessibility come free. And the code somebody maintains is annotations rather than controllers.

Freestyle UI5 means writing the application: views, controllers, models, routing. Total control, and every one of the things above is now yours to build and maintain.

The guidance is genuinely one-sided: use Elements unless the interaction cannot be expressed as one of its floorplans. Most business applications are a list and a detail page, which is exactly what Elements does. Freestyle earns its place for genuinely custom interactions, a visual tool, a guided process that does not fit the patterns.

The failure to avoid is choosing freestyle because it feels more like programming. It produces an app that looks like the standard ones on day one and drifts away from them with every release nobody maintains it through.

SAP Business Application Studio (BAS) is the cloud development environment for Fiori/UI5, with wizards, templates (including Fiori Elements) and deployment tooling. ABAP Development Tools (ADT) in Eclipse handle the CDS/RAP backend. Together they are the modern Fiori toolchain.

Alongside Business Application Studio, the same work can be done in VS Code with the SAP extensions, which suits developers who already live there. Both give the guided application generator, which scaffolds an Elements app from a service in a few prompts and is the sensible starting point rather than an empty project.

An hour, and it demonstrates why Elements is the default.

1. Take a CDS view exposed as an OData service.
2. Run the application generator, choose a list report floorplan, and point it at the service.
3. Run it. You have a working application with filtering, sorting, paging, variant management and export, and you have written no UI code.
4. Add annotations to the CDS view: mark a field as a key column, add a value help, define which fields appear in the filter bar.
5. Reload. The application changed, because the annotations drive it.
6. Now add an object page and a navigation from the list. Still annotations.

Step five is the point. The application is described rather than written, which is why it stays consistent with everything else and why the maintenance burden is small.

Often you extend a standard Fiori app (adding a field or logic) rather than building from scratch, using approved extension points. This keeps you close to standard (clean core) while meeting the specific need.

The order to try, cheapest first: adapt a standard app through the adaptation tooling, which changes the UI without code and survives upgrades. Extend the underlying CDS view with an extension include, adding fields without modifying the original. Build only when neither reaches. Each step up is more capability and more to maintain through every release.

Follow the clean-core principle: build extensions on approved frameworks (side-by-side on BTP, or in-app via released APIs), not by modifying standard, so your apps survive upgrades and cloud moves.

In practical terms it means three habits: consume released APIs rather than reading tables, extend through provided extension points rather than modifying, and put anything substantial on the platform rather than in the core. The test is simple, and it is what the principle exists for: could this system be upgraded next quarter without anybody rewriting your work.

If Fiori Elements generates the app from the model, then the model's annotations are the development, so knowing the main groups makes the approach usable.

UI annotations decide presentation: which fields appear in the list, in what order, which are in the filter bar, how the object page is divided into sections, what the header shows. These are the bulk of the work.

Value help annotations attach a search help to a field, so a user picks from valid values rather than typing.

Semantic annotations tell the framework what a field means: this is a currency amount and that is its currency, this is a unit of measure, this is a criticality that should be coloured. That is how numbers format correctly and how a status shows red or green without anybody writing a formatter.

Search and analytics annotations enable free text search and mark measures and dimensions for analytical floorplans.

Where they live is a decision. Directly in the CDS view is simplest. In a separate metadata extension keeps presentation apart from the model, which matters when the same view serves several consumers, and it is the better habit for anything reused.

The realisation that makes this click: you are not configuring a screen, you are describing what the data means, and the screen follows.

• Elements or freestyle. Elements unless the interaction genuinely cannot be expressed as a floorplan, which is less often than developers expect.
• Adapt, extend or build. In that order, cheapest first, because each step up is more to maintain through every release.
• Where the logic lives. In the CDS model and the behaviour definition, so it applies wherever the data is consumed, rather than in a UI controller where only that app benefits from it.
• Which UI5 version. Pinned per custom app and recorded, because the breakage appears after an upgrade and reconstructing what changed is harder than writing it down.

• Freestyle builds where Fiori Elements + RAP fit.
• Modifying standard apps instead of using extension points.
• Ignoring clean core, painful upgrades later.

• Freestyle for a list and a detail page. Elements does that, better, for free.
• Modifying a standard app rather than adapting it. The upgrade is then a merge.
• No UI5 version pinned for a custom app. See the launchpad, performance, security and the development system for the surrounding concerns.

• Annotations buried in the base CDS view. Presentation belongs in a metadata extension, so the same model can serve several consumers without carrying one consumer's layout.

Generating an app is the easy half, and modelling the CDS view and annotations behind it so the application is describable rather than written is the part you do in the course.

The instinct to build: describe rather than write. If you are writing a controller for a list and a detail page, there is an annotation that would have done it, and the generated version stays consistent with every other app when the framework moves.