Exploring the Overview Page (OVP)

The basic structure and appearance of the overview page is governed by the dynamic page layout, and is divided into a header area and a content area.

This enables you to use variant management, text, and a smart filter bar in the upper part of the screen (dynamic page header). The content of the overview page is presented using cards.

Two different layouts are available which determine the size and position of the cards fixed card layout and resizable card layout.

Cards are containers for app content, and represent an entry-level view of the most pertinent app data for a given topic or issue. The overview page can contain several cards that reference the same underlying application. However, each card must bring added value to the user, and not just repeat information already offered on another card.

Cards can display different types of content. They can show a chart, a list, a table, informative text, or a combination of two elements. Cards can also vary in size, depending on the selected layout. However, cards never have editable fields.

When designing cards, make sure that you define and format the texts on all the cards consistently.

The overview page supports different standard card types.

In addition to these cards, the overview page also supports custom cards. Custom cards allow you to define the appearance of a card on an overview page, and the type of content that appears in the card content area. They offer additional flexibility when you require features that are not offered by the standard cards for overview pages.

You can use the following properties to configure an overview page:

• smartVariantRequiredEnable/Disable the smart variant management control on the smart filter bar.
• showDateInRelativeFormat Show date on the SFB like yesterday, tomorrow, and so on.
• enableLiveFilter Show/Do not show the Go button on the smart filter bar.
• refreshIntervalInMinutes Refresh the OVP every x minutes, minimum is 1 min.
• useDateRangeType True // true to enable Semantic Date, default false.

Topic: useBatch: false (https://sapui5.hana.ondemand.com/#/api/sap.ui.model.odata.v2.ODataModel/constructor)

Consider a scenario where you have one analytical card and four transactional cards (list, table, stack, linklist) in your OVP application. The HTTPS requests made by the analytical cards are generally heavy (take a long time). Since analytical information is based on aggregated entity sets, the back end requires time to process each http request. If all the cards in your application use the same model (datasource), then in such a scenario there would be only one batch request for all the cards to fetch data. Since the calls for analytical cards take too long, the other four cards would also not display any data. This scenario can be handled by creating two separate models in the application manifest and disabling batch mode for the analytical card model. In this case, the response from the back end would be quicker and you would see the OVP being rendered relatively quickly.

preload: true (https://blogs.sap.com/2016/11/19/sapui5-application-startup-performance-advanced-topics/ - Section: Use model preload feature)

This is a way to load the metadata and annotations before the OVP application load, so that OVP does not have to 'wait' for the metadata and annotations and can continue directly with rendering the UI.

General performance guidelines: if you have analytical cards that take a long time to return data, you can consider disabling the batch mode (the rationale being that multiple small requests fired almost in parallel time would be faster when compared to one heavy batch call). Ideally, the suggested way is to have one model in the manifest which all the analytical cards would use and one model in the manifest which all the transactional cards would use.

All the data fields are displayed at the left-hand side. All the data points are displayed at the right-hand side.

For now, we will have to use the local annotation approach because the datafieldForAnnotation annotation is not yet supported by CDS.

The card configuration for stack cards looks like the following:

1234567891011
"card02": {
  "model": "mainService",
  "template": "sap.ovp.cards.stack",
  "settings": {
    "title": "{{card02_title}}",
    "subTitle": "{{card02_subtitle}}",
    "entitySet": "ZCDS_UX403_OVP_00",
    "annotationPath": "com.sap.vocabularies.UI.v1.FieldGroup#DETAILED"
  }
  }

The content of the card is implemented as FieldGroup-Reference-facet.

The content of a stack card is implemented by using headerinfo and fieldgroup annotations

1234567891011121314
@UI.headerInfo: {
typeNamePlural: 'Sales Orders',
typeName: 'Sales Order',
imageUrl: 'SAPIconUrl',
title: {
label: 'Sales Order ID',
value: 'SalesOrder'
},
description: {
label: 'Sales Order Item',
value: 'SalesOrderItem'
}
}

Annotate fields of the projection list as fieldgroup items @UI.fieldGroup:[{position: 20, qualifier: 'DETAILED', label: 'Product Category'}].

Create the Fieldgroup-Reference facet with reference to configured field group id.

1234567

@UI.facet: [{ 
type: #FIELDGROUP_REFERENCE, 
targetQualifier: 'DETAILED',
isSummary: true 
}]

The manifest.json configuration of an analytical card showing a donut chart looks like the following:

123456789101112
"card01": {
  "model": "mainService",
  "template": "sap.ovp.cards.charts.analytical",
  "chartType": "cardchartsdonut",
  "settings": {
    "title": "{{card01_title}}",
    "entitySet": "ZCDS_UX403_OVP_00",
    "identificationAnnotationPath": "com.sap.vocabularies.UI.v1.Identification",
    "chartAnnotationPath": "com.sap.vocabularies.UI.v1.Chart"
  }
  },

Documentation: https://help.sap.com/viewer/468a97775123488ab3345a0c48cadd8f/7.52.3/en-US/530f9e6f66104d5888ade79b5cf417e0.html