Fiori Development – Creation of a List Report using Fiori Elements
1. Introduction
In our previous blog, we demonstrated the creation of a simple ‚Hello World‘ application and deployed it on an S4 on-premise system. Building on this post, this blog will introduce Fiori Elements and guide you through the creation of a List Report including an Object Page, showing further details related to the selected item. This blog aims to show the power of Fiori Elements as a framework, which allows for rapid and efficient app development without extensive custom coding.
2. Fiori Elements
Fiori Elements is a framework for SAP Fiori app development that provides out-of-the-box templates to create standard applications efficiently. It enables developers to create applications without the need to use JavaScript. Compared to a freestyle app, the file structure in a Fiori Elements app differs, as much of the app configuration and design is managed via annotations, either locally or in the backend. Fiori Elements provides several templates, each serving distinct purposes.
In this blog, we will focus on creating a List Report based on a CDS view entity defined in the backend system. The app will show us a list of products with several columns containing further product details. By clicking an item in the list, you navigate to a detail page (Object Page) which provides further information related to the product.
Local and Backend Annotations
As mentioned, apps based on Fiori Elements are designed using annotations, which can be defined locally in the frontend (in the annotation.xml file) or in the backend, specifically in the CDS view or view entity. It should be noted that not all available UI annotations are supported in the backend, which means that local annotations will inevitably be required at some point, especially when working with more complex floorplans like the Overview Page. However, it is not advisable to define every possible UI annotation in the backend. Generally, it makes sense to define annotations for individual fields or the entire view directly in the CDS view.
However, I will deliberately demonstrate how more complex annotations, such as those for UI facets, can also be utilized in the CDS view entity.
3. Data Source
The basis for our data source, the OData service, is a simple CDS view entity which selects some product information:
We defined several important annotations, like the one for the OData service definition and UI annotations which help shape the layout of the app. Beside the UI annotation for the header value, we also use the UI.lineItem annotation for bringing the fields in the required order in the initial report layout.
The field GrossWeight was enhanced with additional formatting as you can see in the details of the UI.lineItem annotation. With the help of the StatusColor field, values below or above certain thresholds are highlighted accordingly. You can choose whether to use icons in addition to the color highlighting
The criticality which is shown in the field StatusColor in this example, was defined in a different view entity one level below.
As the OData service is the data source for the app and not the CDS view entity, you can check whether the generated service contains all information from the view entity by calling the metadata document:
https://<host>:<port>/sap/opu/odata/sap/-name of the OData service-/$metadata
The data structure is described in the so called EDMX format (Entity Data Model XML). It defines the data in a way that applications, such as Fiori apps, can consume it.
4. App Creation
Please note that setting up the connection between the BTP and the backend system is a prerequisite for carrying out the following steps. You can check my Blog FIORI Development – Connect BAS to On-Premise System for details.
For the creation of the app, we first set up a new project using the SAP Business Application Studio and choose the Fiori List Report as template:
We connect to our backend system and search for the required OData service which was generated out of the CDS view entity and activated in /IWFND/MAINT_SERVICE:
Next, we define the main entity and the table type. As our CDS view does not contain analytical capabilities and we plan to use the app on a desktop mainly we choose “Grid”.
This table type is suitable for desktop based display. It enables features such as filtering and selection capabilities in the app and can handle a large number of items and columns. After completing the project creation, we add it to the workspace. After following these steps, the projects structure appears in the workspace:
5. Preview
The annotations defined in the backend are only evaluated at runtime. They dynamically influence the layout and behavior of the app when it is launched, allowing the UI to be constructed based on the annotations without requiring manual adjustments in the frontend code. In case of a List Report the app should already work after the project creation and should show you the layout according to the annotations defined in the CDS view entity:
If you want to avoid the filter step and directly execute the report at app start, you can achieve this by a small adjustment in the manifest.json file:
In the app preview the List Report is shown, created entirely through the previous CDS view definitions without any UI-level scripting:
You can set filters for all fields or adjust the layout and change the position of the fields at runtime. If there are fields in the CDS view entity which have no UI annotation assigned which determine their position in the layout, you can show them afterwards at runtime:
6. Object Page
We don’t want too much information about the products in the row, that’s why we use a detail page, known as Object Page, to show further information. This opens upon clicking the arrow on the far right of the row. At this point, the advantage of using Fiori Elements becomes clearly evident once again. This Object Page, as well as the routing and navigation to it, does not need to be implemented with complex logic, it was generated automatically. We only need to define which information we want to display and how we want it to appear on this page. This is done via annotations, which can be defined directly in the CDS view entity or locally with a different syntax in the annotation.xml file. It is necessary to become familiar with the various UI annotations for this.
We set the required annotations in the CDS view entity:
With the use of a facet we created a section within the object page and assigned a field group which contains three more fields to it. After that you can click on the arrow on the far right of a row in the List Report, and the object page will open and show the data accordingly:
The successfully tested app can now be deployed to the backend system.
It should be mentioned that this was a very simple example of a List Report and Object Page. You can theoretically do much more using this template, like incorporating for example analytical objects like charts and KPI’s into the Object Page.
7. Conclusion and Outlook
We explored the use of Fiori Elements to create a List Report and corresponding Object Page. By leveraging annotations and the available templates, developers can create powerful applications without extensive front-end coding, significantly reducing development time. Before we dive deeper into the topic of Fiori Elements and explore additional templates, I will demonstrate in the next blog how to create an SAPUI5 freestyle app that allows maintaining data in the backend system.