Introduction

When we look at Fiori Elements, we see the opinionated design that helps drive us towards a unified user experience (Fiori in general), floorplans that resolve common business application scenarios and tools such as Annotations that can be used to enrich OData services and shape our application’s behavior. In previous articles in this series, a general overview of Fiori Elements was provided along with an explanation of SAP-Specific and Vocabulary-Based annotations. We then reviewed configuration of the Smart Filter Bar within the List Report floorplan and making modifications (search helps, date range selection) to controls therein.

For this article, I wanted to shift attention from the Smart Filter Bar to the Smart Table within our List Report floorplan. We will discuss rendering options and initial setup, applying modifications to the manifest.json file within our application, and briefly discuss the service requirements for the Smart Table to function properly in the form of an Analytical Table.

Configuring the Smart Table within our List Report

The Smart Table within our List Report is, essentially, a wrapper around existing SAPUI5 tables. It helps lessen the development effort (as is the case with many abstractions) but comes at the expected cost of the loss of some fine grain control. By default, the List Report’s Smart Table will render in the form of a Responsive Table but configuration changes can be made to allow it to take the form of a Grid Table or an Analytical Table. You will need to refer to the Fiori Design Guidelines for each respective table to determine which type best suits your design.

The Responsive Table

We are going to turn our attention to the manifest.json file that, outside of our component.js, is the point of entry into our application. The Web IDE has carved out a bit of this for us when we initially set up our List Report application by selecting “New Project from Template”. Below you will see an example of the initial configuration of the List Report and Object Page of our application. With this set up, our application will leverage the Responsive Table with the ability to act on/select one row at a time.

Initial Configuration within Our Manifest.json

If we require a custom action to be defined for our List Report that has the potential to act on multiple result rows, we can implement the multi-select feature for our Smart Table. Our custom action will not have any parameters and will act on any selected context(s). Below you see the manifest.json configuration change we have made that will result in a multi-select Responsive Table with an arbitrary action/button (to allow multi-select to work) that will fire the “onApproveContract” function when it is pressed.

Manifest.json: Multi-select Settings

In future installments, we will dig into the configuration of extensions for our applications but, for now, I have created a new extension controller for our List Report and carved out our “onApproveContract” function. The new controller will reside under an “ext” extension folder within the “controllers” sub-folder as shown below.

Within the controller, I’ve set up the predefined controller lifecycle hooks along with our “onApproveContract” function.

sap.ui.controller("demo.sap.contractreviewdemo.ext.controllers.ListReportExtension", {
    onInit: function() {},
    onExit: function() {},
    onBeforeRendering: function() {},
    onAfterRendering: function() {},
    onApproveContract: function(oEvent) {
        var aContexts = this.extensionAPI.getSelectedContexts();
        if (aContexts && aContexts.length > 0) {
            //Perform Action
        } else {
            sap.m.MessageBox.error("You must first select a row!", {});
        }
    }
});

An Overview of the ListReportExtension Controller

The results of our changes are as follows:

We now have multi-select capabilities enabled for our Responsive Table

For reference: single select Responsive Table

Please note that we have other setting options at our disposal including the control of variant management for our List Report. Variant management allows for storing snapshots of a user’s setting when using your application such as filters within the Smart Filter Bar or visible columns within the Smart Table.

By default, the Smart Filter Bar and Smart Table each have their own variant (See above where both are set to “Standard”). If we use the setting “smartVariantManagement“: true we will now have a unified variant management area for our List Report where variants for both the Smart Filter Bar and Smart Table are saved together.

The Grid Table

Instead of the default Responsive Table, we could make a small change to our manifest.json file (below) to set the Smart Table within our List Report floorplan to render as a Grid Table. In this example, we are also configuring our Smart Table for multi-select and our List Report to leverage unified variant management:

Manifest.json: Changes Required for a Multi-select Grid Table Setup

The expected result is a Grid Table with the option to select multiple rows. You should also notice the new “Show Details” button at the top-right of the table. With a single row (checkbox) selected, we can use this action to navigate to the Object Page (Details). For more information on the Grid Table’s anatomy and when and how to use it, please refer to the Fiori Design Guidelines.

We now have the Smart Table rendered as a Grid Table

The Analytical Table

If we wanted to now transform this Grid Table into an Analytical Table, we’d have to do some work on the OData service’s metadata model within Gateway (SEGW) as this is what governs the sort of change we require. First and foremost, we would need to set the SAP annotation of “semantics” to “aggregate” (sap:semantics=”aggregate”) for the entity being represented in our Smart Table (in this case, the Contract entity type). On top of that, the analytical table naturally requires data that has been classified into aggregation-roles (dimension, measure or empty) to consume and manipulate properly. Without at least one measure defined, you will encounter an issue with duplicates groups and rows in the Analytical Table when grouping.

An Analytical Table with no Defined Measures (Duplicate Rows/Groups when Grouping Example)

In this demonstration, I am using mock data and not connecting to a live service that could supply the necessary data for a fully functional Analytical Table. Behind the scenes SAPUI5 is bundling several OData service calls in a batch request to retrieve the necessary entities and their associated properties along with aggregate query results. These aggregate query results supply the Analytical Table with the required totals and subtotals that are missing in the screenshot below.

Our Analytical Table with Missing Totals and Subtotals

If we wanted to create our own analytical OData backend, it would require a bit of work outside of setting specific SAP-specific annotations within the Define method of our Model Provider Extension class. If you are leveraging SADL and mapping your entities to a CDS View data source, you would need to specify an Aggregation Method for your measures using the query options API provided by the framework. On 7.50+ systems you have the options of integrating your annotations into your CDS Views and may specify the aggregation behavior in a different manner.

METHOD IF_SADL_GW_QUERY_CONTROL~SET_QUERY_OPTIONS.

  CASE iv_entity_set.
    WHEN 'ContractSet'.
	
      "Set aggregation method for analytical measures:
      io_query_options->set_aggregation( VALUE #( ( 
        element = 'NET_VALUE' alias = 'NET_VALUE'
        type = if_sadl_gw_query_options=>co_aggregation_type-sum ) ) ).

    WHEN OTHERS.

  ENDCASE.

ENDMETHOD.

Specifying the Aggregation Method for our Measure via the SADL API

Complete setup of an analytical OData backend is outside the scope of this article but, hopefully, some of the links provided in herein will get you headed in the right direction. Once your service is configured properly, the underlying technologies understand how to assign any group by clauses to generated queries against your data source to bring back the proper aggregate data.

An Example Metadata (EDMX) Document Required for an Analytical Table

Conclusion

I hope this entry has been helpful in illustrating some options you have as developers when configuring the Smart Table within the Fiori Elements List Report floorplan. In future articles, I plan to explore methods of extending our application by adding new columns to our tables, new filters to the Smart Filter Bar and new views to the Object Page.

For other articles in this series, please refer to the list below:

• Annotating and Extending Fiori Element Applications
• Annotating and Extending Fiori Element Applications: List Report Part 1 (Smart Filter Bar Configuration)
• Annotating and Extending Fiori Element Applications: List Report Part 2 (Smart Filter Bar Configuration Continued)
• Annotating and Extending Fiori Element Applications: List Report Part 3 (Smart Table Configuration)

Some Resources to Consider

• Using OData Analytics in SADL-Based Services
• SAP – ABAP Programming Model for SAP Fiori
• SAP Annotations for OData Version 2.0
• List Report (SAP Fiori Element)
• Vocabulary-Based Annotations
• OData 4.0 Vocabularies – SAP UI
• OData 4.0 Vocabularies – SAP Common
• Overview (OData Version 2.0)
• Fiori Elements – Why cookie cutters make me happy
• Fiori Elements – How to Develop a List Report – Using Local Annotations
• com.sap.vocabularies.Common.v1.xml
• com.sap.vocabularies.UI.v1.xml