The flexible programming model makes it easy for you to extend apps based on SAP Fiori elements for OData V4. While you're free to use any SAPUI5 coding or controls in extension points, you can also take advantage of our new building blocks. Leveraging the building blocks gives you even more possibilities to adapt your apps with a minimal amount of custom SAPUI5 coding. In this blog I will give you an overview of the flexible programming model and point you to the relevant documentation.
A great UX needs the right balance between UX consistency and use case specific design. Hence the ability to extend SAP Fiori elements apps with SAPUI5 freestyle code and controls has been a key factor in its success. However, the drawback of having the flexibility to extend SAP Fiori elements apps is that both development and maintenance efforts increase with the number of individual changes you make.
With the flexible programming model, and in particular the building blocks, we give our customers and partners the ability to create extensions, while maintaining UX consistency and limiting the cost and complexity of the extensions.
In short, the flexible programming model allows you to
Increase the lifecycle stability of your apps and lower maintenance efforts by reducing the amount of custom SAPUI5 coding
Further boost development efficiency by taking advantage of standard SAP Fiori elements functionality, such as draft handling or side effects also in your extensions
Retain UX consistency for your extensions
How it works
The flexible programming model incorporates three features to add custom functionality to standard SAP Fiori elements apps:
Manifest-based extension points allow you to add custom artifacts like custom sections, custom actions, custom table columns, or even custom pages. The concept is comparable to that of SAP Fiori elements for OData V2, plus you have the ability to add whole custom pages into your navigation flow.
Within these custom artifacts, developers can use any SAPUI5 control and can make use of the new SAP Fiori elements building blocks.
These building blocks are reusable artifacts that are orchestrated by the SAP Fiori elements runtime. A building block has a data binding to parts of the OData V4 service that the app is based on. It is basically a wrapper around one or several UI5 controls and feeds them with UI configuration that it derives from the app configuration and metadata.
Using building blocks, you automatically benefit from SAP Fiori compliance and standard application behavior orchestrated by the SAP Fiori elements runtime like draft handling, side effects, or navigation.
The building blocks are a subset of the scope that is also used within the SAP Fiori elements framework to build our SAP Fiori elements floorplans. So far we have published a first set of building blocks and intend to publish more depending on usage and demand.
Essentially, the building blocks for our OData V4 stack are an evolution of the smart controls for OData V2 – with improved architecture, cleaner code, better performance, and enhanced functionality.
Controller extensions offer hooks into SAP Fiori elements functionalities so you can override or extend the standard logic, for example in the edit flow or message handling.
Flexibility in arranging your pages within your app
Another important aspect of the flexible programming model is the advanced flexibility for page composition of your apps: SAP Fiori elements for OData V4 uses standard UI5 routing instead of pre-defined patterns. This enables for example
the navigation to different object pages from one list report
an app that consists of a single object page only
a custom page anywhere within the app structure
With the flexible programming model, we are taking another step in harmonizing the development of custom coding and standardized SAP Fiori elements apps. How will you use the flexible programming model and building blocks to extend the capabilities of your SAP Fiori apps? Looking forward to your feedback!
On behalf of the SAP Fiori elements team, stefanie.runde.