Flexible Programming Model

The flexible programming model is not a separate framework but a set of options SAP Fiori elements for OData V4 offers for going beyond the floorplans while the framework stays in charge:

1. Extension points in list reports and object pages accept custom sections, columns and actions written in SAPUI5.
2. Building blocks place metadata-driven elements, such as a table, filter bar or field, wherever needed.
3. Controller extensions and the ExtensionAPI let custom code react to framework events such as saving or navigation.
4. Custom pages add a page with its own XML view to the app's routing. The page runs on the SAP Fiori elements runtime (component sap.fe.core.fpm), with the OData binding context, navigation to standard pages and building block support.

The flexible programming model is therefore a sliding scale between generated and hand-written UI, decided page by page and section by section.

Building blocks are reusable, annotation-driven UI elements of SAP Fiori elements for OData V4, the same elements the framework uses to assemble its floorplans.

• Not controls, but templates. A building block is a set of templating instructions. At runtime it produces controls that fit the bound data: a text for a string property, a date picker for a date.
• Configured in three places. Service annotations define the default behavior, inline XML attributes refine it, and the manifest overrides both when they conflict.
• Referenced by metadata path. A building block points at an entity set, a property or an annotation instead of binding columns by hand.
• Examples: Table, FilterBar, Chart, Field, Share and Page.

Because they read the same annotations as the floorplans, building blocks inherit variant management, personalization and draft awareness. Building blocks are the reason a custom page can still look and behave like a standard SAP Fiori elements page.

SAP's guidance is to use as much SAP Fiori elements as possible and as much freestyle SAPUI5 as needed:

All four can live in one app: a supplier cockpit at Alder Manufacturing could combine a custom chart with a standard Table building block, then open a standard object page.

Decision test: if a page you plan to build freestyle contains a standard filter bar and table, try a custom page with building blocks first. The flexible programming model is the right choice when the layout is custom but the parts are standard.

• No rigid choice. Teams do not have to abandon SAP Fiori elements the moment a requirement falls outside a floorplan.
• Standard behavior for free. Building blocks bring filtering, variants, messages, draft handling and accessibility from the framework.
• Annotations stay the source of truth. A label changed in the service annotations updates floorplan pages and custom pages alike.
• Supported extension surface. Controller extensions and the ExtensionAPI give custom code documented hooks that are easier to keep stable across SAPUI5 upgrades.

For OData V4 apps, the flexible programming model is the most direct way to add custom UI without giving up what SAP Fiori elements already provides.

• OData V4 only. Building blocks and custom pages belong to SAP Fiori elements for OData V4. An OData V2 app keeps the V2 extension points; adopting the model means moving app and service to V4.
• Version-dependent. Building blocks arrive release by release, so an app can use only what the target system's SAPUI5 version offers; the API reference lists the release in which each building block became available.
• Not every floorplan feature carries over. SAP documents, for example, that creating a card for the Insights section of My Home is not available when the table building block sits in a custom page or custom section.
• Freestyle use has prerequisites. Building blocks can appear in freestyle SAPUI5 apps, but the setup each building block needs should be checked in the SAPUI5 documentation for the release in use.
• SAP S/4HANA Cloud Public Edition follows its own extensibility rules for customer-built apps; check that edition's documentation before planning one.

The flexible programming model widens what SAP Fiori elements can do; it does not remove the dependency on OData V4 and on well-designed annotations.

1. Rebuilding standard elements by hand. A custom table with its own filter logic duplicates the Table and FilterBar building blocks. Configure the building block instead.
2. Configuring in three places. When annotations, XML attributes and manifest settings describe the same table, the manifest wins and the others look broken. Pick one place per setting.
3. Loading fragments the wrong way. SAP requires dynamically loaded fragments that contain building blocks to be loaded through the ExtensionAPI method loadFragment.
4. Fixing the UI instead of the service. A missing label is usually an annotation problem; patching it in custom code hides it from every other page.
5. Ignoring production's SAPUI5 version. Building blocks tested on the newest release can be missing on the front-end server.

Most flexible programming model problems are configuration or layering mistakes, not limits of the model itself.