Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 4 of 6

Fiori elements building blocks and flexible programming model

10 min

Listen to this lesson

0:00 / 7:17

The fear that stops teams from rebuilding in Fiori elements is losing the custom bits. The answer for OData V4 apps is the flexible programming model (FPM): a set of extension options and reusable building blocks that let you add custom sections, columns, actions or whole custom pages to a Fiori elements app, while the framework keeps owning everything else. Done well, FPM keeps the rebuild small, upgrade-friendly and clean of the legacy patterns the linter flags.

Building blocks

Building blocks are Fiori elements controls you place in your own XML views or fragments, from the sap.fe.macros library. They are driven by the same metadata and annotations as the floorplans, so a building-block table in a custom section behaves like the tables in the rest of the app: same personalization, same export, same draft handling. SAP's Flexible Programming Model Explorer, part of the SAPUI5 documentation, shows each building block and extension point with live samples and code.

Building blockUse at ContosoWhat it saves
TableClaim items inside a custom section of the claim object pagePersonalization, export, draft-aware editing
FilterBarFilters on a custom analysis pageValue helps and variant management from annotations
FieldA single annotated field in a custom fragmentFormatting, value help, edit mode from metadata
FormA group of fields from a field group annotationLayout and edit handling
ChartClaim counts by month on a custom pageChart wiring to the OData service

Common building blocks and where Contoso uses them. Check the FPM Explorer for the current list and properties.

Extension options

AnnotationsChange what the floorplan shows: line items, field groups, facets, criticality
Manifest settingsConfigure tables, actions, navigation and variants without code
Custom columns, sections and actionsSmall XML fragments and handlers placed at defined extension points
Controller extensionsOverride documented lifecycle hooks of the page controllers
Custom pages with building blocksA whole page of your own, still built from Fiori elements parts
The extension options of a Fiori elements V4 app, from least to most custom code.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-206

Use the lowest layer that solves the problem. Kenji's rule for the claims rebuild: annotations first, manifest second, a custom section with building blocks for the claim timeline, and a controller extension only for the single action that calls the warranty pricing API. Each step up adds code Contoso must maintain and test.

Kenji's escalation path for a requirement: every step down the chart adds code to maintain and test.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-206

Walkthrough: the claim timeline section

  1. In SAP Fiori tools (in SAP Business Application Studio or VS Code), open the Page Map for the claims app and add a custom section to the object page.
  2. The generator creates an XML fragment and an entry in manifest.json placing the section after the Items facet.
  3. In the fragment, add a macros:Table building block bound to the claim's status history navigation, with the line item annotation that lists date, status and user.
  4. Keep all module access through sap.ui.define and core:require; no globals, no inline script. Run ui5lint: zero findings.
  5. Give the section and the table stable IDs, which tests will use (lesson 5).
  6. Add an OPA5 journey that opens a claim and checks that the timeline shows the expected entries.
A building block in a custom section uses the same service and annotations as the rest of the page, so it behaves like a native part of the app.
The Sign-Off Table · thesignofftable.com/academy/sap-btp-206

Fiori elements V2 apps

Contoso has a few Fiori elements apps on OData V2 services, generated years ago. They are framework-owned too, so their linter findings are usually in custom extensions. The flexible programming model and the sap.fe.macros building blocks described here belong to the OData V4 stack; V2 apps use their own extension mechanisms. Moving a V2 app to V4 means moving to an OData V4 service first, which is a service project (for example a RAP business service), not a UI change. Contoso moves V2 apps only when the service is being rebuilt anyway, and otherwise lints and tests their extensions like any other code.

Why FPM helps readiness

  • Less code. The custom section is a fragment of a few lines plus annotations; there is little left for the linter to flag.
  • Framework-owned behavior. Draft, personalization and accessibility in building blocks follow SAP's updates.
  • Clear seams for tests. Extension points have stable IDs and documented hooks; tests attach to them, not to generated DOM.
  • Upgrade notes in one place. SAP documents changes per building block and extension point.

What goes wrong

  • Freestyle inside FPM. A custom section that brings back globals and jQuery code reintroduces the debt the rebuild removed.
  • Overriding internals. Controller extensions that touch undocumented framework internals break on the next SAPUI5 update.
  • Unstable IDs. Generated IDs change, and every test that used them fails.
  • V2 assumptions. Building blocks and FPM as described here are for OData V4 Fiori elements; V2 apps use different extension mechanisms.

What would you do?

Elena wants a chart of claims per month on the claims object page. A developer proposes a freestyle third-party chart library loaded from a CDN in a custom section. What should Kenji suggest?

Key points
  • The flexible programming model extends Fiori elements V4 apps with building blocks and defined extension points.
  • Building blocks from sap.fe.macros (Table, FilterBar, Field, Form, Chart) use the app's annotations and service.
  • Escalate from annotations to manifest to extension points to custom pages; each step adds code to test.
  • Stable IDs and documented hooks give tests reliable seams.

Check your understanding · not graded

Lesson check

  1. 1. Which library provides Fiori elements building blocks?

  2. 2. Which extension layer should Kenji try first?

  3. 3. Where can developers browse building blocks with live samples?

  4. 4. Why do stable IDs matter in custom sections?

  5. 5. Which risk comes from controller extensions that use framework internals?