Exploring the Analytical List Page

The ALP has three main components:

• Title Area
• Visual Filters
• Content Area

Let's explore each of these components.

API is a default component for embedded analytics in S/4HANA. The key requirements are as follows:

• OData V2 as the protocol for data exchange
• UI annotations
• Aggregate based entity sets (we use aggregate-based UI controls like visual filters and charts)

Time to check your understanding of when to use analytical list page!

As already described, ALP is based on a analytical model. So the basis for implementing an ALP is that you have implemented an analytical model.

As CDS query runs on Analytic Engine (in BW, it is called OLAP Engine), the data model should still align with traditional BW assumptions. CDS views just provide a faster, easier, more flexible way to build up such a data model.

The upper part of this picture shows the traditional objects in a typical BW system. To report on a BW system: InfoProviders are built by using Modeling Tool for BW on HANA, or RSA1 for BW on other DBs. Then, BW queries are built on these InfoProviders by using Query Designer, either Bex Query Designer or Query Designer in Modeling Tool.

It is similar for a transient query to run on the Analytic Engine in a non-BW system such as SAP S/4HANA. The lower part of the picture shows this. InfoProviders should be built by using CDS views, then CDS queries are built on top of it by using CDS views, but with different annotations.

Planning is not supported in customer defined CDS. See Note 2874534 - Planning on ABAP CDS View).

CDS views are just a new tool to build the data model for Analytic Engine. The only difference is, with traditional tools like RSA1, Query Designer or Modeling Tool, the boundary of different objects are well defined in the tools. The tools guide end users to build a valid model. However, CDS views is much lighter tool with strong capability, by reducing the Extraction, Transformation, and Loading (ETL) effort, a data model can be built very conveniently by typing some CDS scripts. But, the boundary of the objects are blurred. The explicit restrictions defined in traditional BW tools become implicit rules for users to follow in order to build a valid model. Although there is no terms like 'InfoProvider' or 'Query' in the CDS transient objects world, nevertheless users still need to bear this picture in mind while modeling a business scenario. With the concept, you will understand where to define what.

After your analytical model is implemented on the SAP S/4HANA system, follow these steps to create an ALP using the SAP BAS:

This video explains the steps to create an ALP using the SAP BAS.

Check https://sapui5.hana.ondemand.com/#/topic/2a9df06673d34f72b238549d49da8bfb for full list of manifest entries and what are the different values that they can take.

The figure displays the template level settings that can be influenced when creating an ALP based application.

Compact filters dialog lists all the fields in the entity sets which are marked with "sap:filterable"=true. For this field to be rendered as a visual filter, we need in addition to this, the visual filter annotations (a valuelist annotation enhanced with PresentationVariantQualifier).

No support for using compact filters to reduce data set for visual filters for the SAME filter field. For example, there is Product as a filter field in both the compact filter as well as visual filters (say a bar chart Revenue by Product showing top 3 records). Let's say, the user now tries to add a complex condition filter in the compact filter for Product: (Product contains PRO) and now switches to the visual filter.

The user might expect that only the products which contains PRO within it are considered for bringing up the visual filter but this is not the case. And it is so by design. The visual filter is meant to show the top 3 products irrespective of the value for the same field in the compact filter. Nevertheless, the complex condition is seen when one clicks on the (1) in the top right of the visual filter and is correctly carried forward to the content area.

In the example shown in the figure the first two records have PRO within their description and the user might expect that they are shown as highlighted. But at the moment this does not happen. Again, the complex condition that was applied is correctly carried forward to the content area. However currently we do not yet highlight the chart selections based on a complex condition coming via the compact filters.

The ALP ignores the UI.Hidden fields when you select filters if the IN mapping points to a field marked with UI.Hidden in the valuelist entity set. For example, the Status_ID from the main entity set points to StatusCodein the value help entity set (of the visual filter). If the StatusCodeis marked as UI.Hidden, then the incoming value is ignored (https://sapui5.hana.ondemand.com/#/topic/16d43eb0472c4d5a9439ca1bf92c915d).

The key characteristics of visual filters are as follows:

• Pre-determined sorting criteria - CANNOT be changed by design!
• Supports semantic coloring.
• Auto determination of scale factor - ALP determines the best scale factor via SAPUI5 APIs based on the values plotted on the chart.
• Decimal precision - 0 or 1 ONLY. Applications can influence via UI.DataPoint.NumberOfFractionalDigitsconnected to the visual filter.
• Adapt filter dialog and personalization.
• Selection in one visual filter could be used as a filter to refresh another visual filter. It is enabled via IN mapping within the Common.Valuelistsnnotation.
• Visual filters could be configured to show always a fixed set of values rather than the top three or bottom three values.

The following steps show you how to create a visual filter.

Visual filters support semantic coloring. Semantic coloring is based on the defined Criticality in DataPoint annotations. The specified value, or the value returned from a path, determines the color.

Both UI.Criticality and UI.CriticalityCalculation annotations are supported. The first one allows applications to have their own backend logic to calculate the semantic color for a given data point value.

The second one allows applications to specify either fixed or dynamic values using which the ALP framework would apply semantic color on the chart data points (https://sapui5.hana.ondemand.com/#/topic/1714720cae984ad8b9d9111937e7cd38).

The following figure shows an example definition for a value help for a visual filter.

FLP default values are applied only in non-navigation context, for example, if you launch an ALP app directly from an FLP tile, there is no xapp-state navigation involved.