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.