Extending SAP Fiori elements Applications – What you need to know
There are many blog posts already written by experts on SAP Fiori elements & its importance in building enterprise ready application. My personal favorites are added in the References section. I would strongly recommend to have a quick peek to at least one of those, if you have not done this so far.
Jocelyn Dart , in her blog post explains that SAP Fiori elements is not an answer for every Fiori application. App developer should check whether their app requirements match with the standard templates provided by SAP Fiori elements & make the choice. Nearly 80% of the Fiori applications in S4Hana is built using SAP Fiori elements, It should be a rare scenario where your application requirements is not addressed by SAP Fiori elements.
This sounds very simple, if the requirement matches with a SAP Fiori elements template use SAP Fiori elements else build a SAP UI5 application. But real world scenarios are not black or white but more grey. I mean many times analysis may result in to SAP Fiori elements template meeting ~80% to 90% of requirements but deviating ~10% to 20%.
To address these grey areas, SAP Fiori elements allow developer to extend the application. SAP Fiori elements application extensions are used in unavoidable situations where annotated approach is not able to address the requirement. This is majorly because the extension code belong to the application developers and will need to own the same across design changes or version upgrades,..etc
By end of this blog post, you will understand different extension possibilities offered by SAP Fiori elements and when to use what.
Deep Dive – Supported Extensions
SAP Fiori elements allows extending the application in different ways based on the use cases. We will discuss each of these topics in detail. In this blog post, I intent to discuss only extending the applications from a developer perspective (provider side) and not adaptation/personalization capabilities (which is more a consumer side customization).
UI Adaptations (Runtime)
Smart Controls & UI5 controls are aggregated to create view. These controls exposes properties which are configured by SAP Fiori elements always based on the design guidelines. Some of these properties could be influenced by annotation but others can’t be. Similarly controls may have to be grouped or may have to be rearranged on the UI for better acceptability. Application developer may wants to configure the properties of these controls to a non default or SAP Fiori elements set value. SAP provides SAPUI5 Visual Editor where the SAP Fiori elements app can be started and changes can be created to address these requirements.
Application developer should ensure to check the documentation & only create the changes which are officially documented as supported by SAP Fiori elements. This is critical otherwise in future releases, your changes may not be considered in a consistent way. You can see more details on allowed UI Adaptation changes here.
SAP User Experience team spends considerable time in defining the most simplest way to represent the data on the UI. SAP Fiori elements & underlying smart controls use these guidelines against the service metadata & renders the UI. But in some unique scenarios view created out of these annotations & guidelines are not enough to make it consumable. SAP Fiori elements allow these specific scenarios to be created as a XML views or fragments and integrate in to SAP Fiori elements app. This approach is called as View extensions. Web IDE Fullstack can be used to create such view extensions on a SAP Fiori elements application. SAP Fiori elements view extensions capabilities can be explained from specific component (like LR, OP, ALP, or OVP) perspective
One of the most commonly used template for display scenarios of the application. The template is constructed out of three major UI artifacts called as Smart Filter Bar, Smart Table & Actions. SAP Fiori elements allow extension on each of this UI artifacts. Below links can take you to the documentation related each of these artifacts & provide details about different view extension possibilities
Most commonly used template for displaying the 360-degree view of an object. This template contains three major UI artifacts, Header Facet, Section (UI Facets) & Actions (Global & determining actions). Below links can take you to the documentation related each of these artifacts & provide details about different view extension possibilities
Analytical List Page
Template is used by the application which needs to analyze the data from different perspective. This template is very similar to the List Report mentioned above and provide similar view extension capabilities. The only additional artifacts in this template compared to List Report is the Chart. You could see overall extension support provided by ALP in the documentation here.
Template is used by developer to model dashboard like applications. The main UI artifacts which construct the OVP is Smart Filter Bar, Actions and Cards. Below links can take you to the documentation related each of these artifacts & provide details about different view extension possibilities
In the above section we discussed how to influence & extend the view of SAP Fiori elements app. Is that enough? I am sure there are scenarios where application developers would like to influence the standard behavior. For an example if an application is launched, app developer wants to adjust some specific start up parameter, whenever a table try to read the data app developer wants to add some additional filters, …etc. SAP Fiori elements supports controller extensions which can be used for addressing these requirements. I will try to explain the controller extensions based on the type of support offered by SAP Fiori elements.
Controller Framework Extensions
Application developers can create extension classes for the controllers (List Report, Object Page, ALP & OVP). This can be done using WebIDE or making the changes in the manifest as described in the documentation here. Developer can provide controller extensions for a specific type of component only once in an Application. You can follow the help document links provided below explaining the methods which could be implemented by application developer in the controller extensions. These methods will be called at specific point in the lifecycle of the SAP Fiori elements applications with arguments or expecting a return value. Application developer could write the custom logic inside this method & influence the standard behavior provided by SAP Fiori elements.
- List Report – Controller Framework Extensions
- Analytical List Page – Controller Framework Extensions
- Object Page – Controller Framework Extensions
Note: Most of the time one controller extension for a component is enough. In cases of an application containing more than one OP, app developer may find this approach as limiting. This can be achieved by providing one extension class in the manifest and on the init method of this controller extension, registering separate extension classes based on the entity type.
Extensions API are provided by SAP Fiori elements which can be used by developer to access state information from the framework or influence or instruct the framework to do certain actions. It is always recommended to use these method whenever possible. You can identify the method details from the documentation mentioned for each supported template
SAP Fiori elements is an annotation based UI Framework. Expectation is that the developer is only annotating the service. As there is no client side code & components are created based on annotations, reuse components is not that important from a SAP Fiori elements perspective. But as explained above it is practically not possible to say that everything which is needed in a business application can be achieved by annotating the service. Let us take an example of Attachments. It looks very simple. But a detail analysis will open up many complex requirements like Upload support (single file, multiple file, drag & drop), download support, Mime type handling, size checks, virus scan, version management,…etc. So many complex requirements to be supported which makes Attachments itself as a service. It may be needed across multiple applications. SAP Fiori elements allow the application developers to create reuse components and embed it back to a standard Fiori element application as part of view in the Object Page. The embedded reuse component can establish communication with embedding component (Object Page) through our extension API. For more details on how to develop and integrate reuse components to SAP Fiori elements applications can be found here.
We discussed how an application developer can extend the UI using View Extensions, influence the behavior using the Controller Extensions, also discussed how to get some complex user experience developed as custom implementation and integrate it with multiple SAP Fiori elements applications. So far so good. Let us look at another situation, where majority of the components inside the application is supported by SAP Fiori elements out of the box but have one or two component where standard template doesn’t fit and specific component needs to be implemented. This is where SAP SAP Fiori elements offers Canvas. The name Canvas is derived from its literal meaning, it offers a place where developer can put custom user experience. More details on how to create Canvas by providing an implementing component for embedding in to canvas can be found here.
Blog post explains different kind of extensions supported by SAP Fiori elements framework & when to use what.
Enjoy SAP Fiori elements 🙂
Feedbacks & comments are always welcome.
thanks for the great blog. I am trying to follow the adaptation project concept to extend on of the standard smart app.. but it says manifest.json does not exist for this app.
what are the options available.
Excellent Blog Vinod! 🙂
Dear Vinod S Nair
Do you know if the Implementation of Actions works the same way in SAP Business Application Studio for SAP Fiori Elements Apps? Following these instructions
the extension in manifest.json unfortunately does not work respectively the desired extra button does not show up.
Hi Vinod S Nair
I'm trying to register multiple controller extensions on the Object Page, but either they are not registering correctly or not being created at all - I followed API of UI5 for the method, but maybe I misinterpreted something there - could you indicate what is wrong with this implementation?
Fiori Elements app extended using in-built Wizard (so automatic creation of manifest.json entries and ObjectPageExt.controller.js file in the app folder)
in the main ObjectPageExt.controller definition I have the following usage of registerControllerExtensions method:
Then I have manually Created another controller JS file in the same ext --> controller folder ChildObjectPageController.controller.js and in its definition I have some functionality onInit
But the logic in ChildObjectPageController is not applied when entering child object page and also I cannot find & open it from debugger tools - also no error in Console.
What is wrong with my implementation - why another controller extension is not registered and fired?
I would like to first mention the usage of AMD with deprecated global for defining extension controller. This is not a recommended model and would run in to unpredictable situation at times. What I mean is that you have used sap.ui.define to describe your dependencies to other modules & created an instance of sap.ui.controller (global object) & returned back. Usage of sap.ui.controller is deprecated from UI5 version 1.56.
So we recommend you to use the sap.ui.define approach which enables the AMD for your module and instead of using the deprecated sap.ui.controller you could simply return a json object as shown below. Your ChildObjectPageController.controller.js should looks something like this below.
Now look at your main controller extension class which is mentioned in your manifest as the extension class for the template type. That should look something like I have mentioned below
This should get your implementation working.
thanks for that informative Blog Post!
Just one open question for me:
Given that a shipped App is already extended with breakouts by Default. How am I able to extend this Application with a new Section on the Object Page which does not come from the Backend and is an pure frontend development.
Normally I would create a new Fiori Elements App and do the extension in the manifest (like mentioned in the UI5 SDK) but in that case the Breakouts from the shipped App will be lost.
Is there a way to extend those Apps as well? I tried the Adaptation Project in the Business Application Studio but there im unable to add a whole new Section.
Any thoughts on this?
Hi Vinod S Nair
I'm have use case where Fiori Elements Flexible Column Layout technically would be a good fit, but with FE framework navigation between second and third object page is intended only with table line items (at least from the SDK samples), but for out process it would be a consecutive step after filling info on Object Page - then Save and move to subObjectPage (EndColumn).
What would be the options to use provided extensions to achieve the continuality of the process? I have now Fiori Elements app from CDS with List Report - ObjectPage and I'm stuck on how to use extensions to trigger navigation to subObjectPage.
Thanks in advance,
in the documentation Extending Delivered Apps Using Adaptation Extensions I find that for the Object Page it's possible to add additional Toolbar actions. But is it also possible to add actions to Tables shown on the Object Page?