Leverage the flexible programming model to extend your SAP Fiori elements apps for OData V4
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.
Learn more and explore sample code using the Flexible Programming Model Explorer
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 Hager.
This is very interesting. Thanks for sharing
Very interesting blog 🙂 Thanks for sharing!
Looking forward to give this a try. Is there a link to the "SAP Fiori Elements Flexible Programming Model Explorer" shown above?
the link to the Flexible Programming Model Explorer should be ready next week and I will update this blog post with it.
Looks developer friendly too. Thanks! for sharing.
Looking forward to get the link to access flexible-programming-model details.
Thanks Stefanie Hager for sharing this. This is a really good step forward to allow further flexibility when using SAP Fiori Elements. Look forward to the Flexible Programming Model Explorer link.
Thanks a lot for Sharing Stefanie Hager - very inspiring!
What UI5 Version is prerequisite for the flexible Programming model?
sorry for my late response, I took a longer summer break this year. The first building blocks were released with SAPUI5 1.91. We have been releasing additional ones with every release and will continue to enhance the scope based on demand.
Thanks Stefanie. Very interesting and promising.
FYI: The link to the Flexible Programming Model Explorer is now available
just one short question for the general approach of the extension of a Fiori Elements App. Let's say as a Customer I want to extend and FE-App which already is shipped with Building Blocks or Custom UI Sections. Is there any way to extend this app with a new extension app? (and therefore not touching the shipped code)
Normally from my understanding you can just extend the base component in UI5, but this seems not to work in a Fiori Elements-App, right?
Hi Sascha Weidlich,
good question, I'm not sure tbh. I'll leave this question up for Stefanie Hager to answer
just to be sure I get the scenario correctly: you have an app that was built using SAP Fiori elements and now you want to extend it using an adaptation project because you don't want to touch the shipped code - correct?
Right now SAP Fiori elements OData V4 apps are not yet supported in adaptation projects - but we are working on this. We then also want to make building blocks available in adaptation projects, but we are still evaluating the feasibility of this. Stay tuned!
Hi Stefanie, hi Marius,
are there any news about this topic? Is it possible to create an extension project for delivered SAP Fiori elemets OData V4 apps, as a customer?
best regards, André!
Will sap.fe replace the 'old' Smart Controls (sap.ui.comp) in the long term? Is a comparison of the two libs available to get a deeper understanding of what was improved or to learn what use cases should be implemented in the future with what library?
sap.fe is our SAP Fiori elements stack for OData V4. It will not make use of Smart Controls, they are only available for OData V2. Instead this stack offers the building blocks as described above.
However, the SAP Fiori elements stack for OData V2 where Smart Controls are used, will continue to be very much relevant and we will continue to support and enhance it.
Ah ok, I see. So basically the used OData version dictates which of the two stacks we are gonna use.
For the map ... Did you used RouteType: Geodesic or any customized route ?
Is there a way in GeoMap that we can customize the route like drawing a curved line instead of flight route ?
we used https://ui5.sap.com/#/entity/sap.ui.vbm.AnalyticMap. Also check the API Reference https://ui5.sap.com/#/api/sap.ui.vbm.AnalyticMap%23controlProperties
Hope this helps,
Yeah I am using GeoMap control and trying to customize the geodesic routeType for Routes as this is not serving the purpose of drawing the curved line which is not a flight route.