Fiori Elements is a framework provided by SAP that simplifies the development process of SAP Fiori applications. Despite it being around past couple of years, my full-fledged application developed started only few months ago. In this blog series, I am continuing my intent to share my experience (as I did when Web IDE was introduced with the blog – My Web IDE story ). The contents are split across two sets of blogs – Part 1 and Part 2. Hope you find the content useful in your development with Fiori Elements.

Introduction

To begin, some introduction to consultants who are new to Fiori Elements. The Fiori Elements framework provides pre-built templates, called floorplans, that provide consistent user interfaces for common application scenarios, such as list reports, object pages, and overview pages using Annotations defined in the CDS-OData service, making it easy to create applications that conform to SAP’s design guidelines and best practices. Key Benefits: Consistency, Productivity, Flexibility and Future-proofing. If you’re looking to create Fiori applications that are both productive and future-proof, Fiori Elements is the right path.

Use Case

The scenario was to re-create or duplicate a standard Fiori elements app. In the copy version, I had to provide custom features for the app. The Standard app had a List report -> Object Page. The custom features handled in the app are as follows:

1. Provide additional filters
   • One filter is a property from the existing entity set
   • Override Annotations
2. Provide Custom buttons in the toolbar
   • UX feature – provide icons to the buttons
3. Invoke a custom OData service with the click of the buttons
   • Usage of JS promise in service calls
4. Remove the navigation from List Report to Object Page
5. « Manifest.json » configurations on the table
   • Multi-selection of elements in the table
   • Provide excel export feature on the table
6. Provide a popup on click of the custom button
   • Integrate the help into the popup fields
7. UX feature – provide an Info toolbar to the table on the selection of entries
8. Adaptation Project of the Duplicate App
   • One filter was a new custom property with predefined values
9. Enable features – Enable Excel export, Growing threshold
10. Change files in the changes folder
11. Launchpad configuration of the adaptation project

Implementation: 

The initial steps were to create a List report project and provide the standard OData service used in the SAP Application and selected the relevant entity as the Target entity. In a couple of steps, the List report and Object page linked to the entity gets created in the project.

Perform a quick test on the app by using the Run button and ensure that data gets loaded in the table with the click of the Go button.

Now, we shall start with custom features in the app.

1. Provide additional filters

The annotation for filters in the List report is : UI.SelectionFields. Since the additional filter requested was part of the CDS based OData entity set, I decided to use the feature of “Clone for Overriding” in Annotation Modeller. Any direct modification of the annotation file from the CDS will be ignored.

The Below screenshot highlights the location of the button to enable the overriding of the properties.

As you see in the screenshot, I have already overridden the UI.SelectionFields and UI.LineItem annotation. Once you click on the button, a copy of the annotation is created by the modeler and you will see a folder named – Local Annotations. In this, you can now insert additional properties into SelectionFields.

Local Annotations folder

Now, the new filter appears in the List Report.

2. Provide Custom buttons in the toolbar

In order to provide custom buttons in the table toolbar, I made use of the Extensions wizard on the project.

On the Project, right-click -> New -> Extension

Create extension on the project

Once the Extension Wizard opens, select the List Report and choose to create an action. You can create a filter, action and additional column using the wizard.

In the earlier feature, I could have used the Extension wizard to create the additional filter. I chose the “Clone for Overriding” option to create the filter to avoid creation of additional fragment.

Now, go ahead and select the entityset bound to the table and provide a label to the button.

On Finish, the button is inserted into the table.

Extension Wizard

The Configurations of the button can be seen in the “manifest.json” file under the selection – extends.

In the definition of the button, I have used the property “requiresSelection” and set it to true. This ensures that button is enabled only when user selects an entry in the table.

UX Feature – provide icons to the button.

Once we choose the feature of extension the framework creates a controller JS file under ext folder.

In the controller file, include the hook method – onInit(). This ensures that code inside onInit gets executed when the page loads. Inside the onInit method, get the ID of the button and provide an icon and set its type.

In the below screenshot, you can see that in the onInit method, we access the button. The IDs of the button are static in nature and hence we are spared of the problem of dynamic ids.

Icon to custom button

3. Invoke a custom OData service on the click of the buttons

The function triggered by the custom buttons was created in a custom OData Service. So, the process of integration of custom odata service into the Fiori elements project is similar to freestyle app. Include the model and datasource declaration of the service in the manifest.json file.

When the wizard creates the custom/extension buttons, it also adds an event handler to the button. The Event handler can be found in the extension controller file – ListReportExt.controller.js

In the event handler method, call the OData service defined in the manifest file. Rest is usual.

I used JS Promise feature in calling the functions as a “Best Practice”.

So, I had a Promise function to invoke the service and return a Promise object. The event handler invoked this Promise function and later use the “.then” and “.catch” methods on the returned promise object.

JS Promise function

Note – async, await shown in the image is not required. It’s the basic personality trait of most developers, to keep trying until we break the code and track the breadcrumbs we return to starting point aka. The Alchemist. 🙂

4. Remove the navigation from List Report to Object Page

I had to ensure that the default navigation due to the annotations in the standard CDS based OData service is removed. So, the user should be restricted from navigating from the table. To block this feature, all I had to do was remove the configuration in the pages section of the manifest.json file.

Remove pages section

5. « Manifest.json » configurations on the table

The List Report table generated by the Elements framework has few configuration options, mangaed through manifest.json file.

Table settings in manifest.json

The further features shall be shared in the Part 2 of the blog, which is “Under Construction”.

Your patience is much appreciated.

As always, I would love to hear your feedback, experience and suggestions. Please use the comment section to share your views.

For further read on Fiori Elements, please use the link: https://community.sap.com/topics/fiori-elements , post and answer questions (https://answers.sap.com/tags/ed5c1ef6-932f-4c19-b2ba-1be375109ff5), and read other posts on the topic (https://blogs.sap.com/tags/ed5c1ef6-932f-4c19-b2ba-1be375109ff5/)