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.

Note

Only use custom cards if the features required for your use case are not offered in any way by the standard cards for the overview page. If your basic requirements can be reasonably covered by one of the standard cards, always use the standard card, even if there are technical or visual limitations.

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

• smartVariantRequiredEnable/Disable the smart variant management control on the smart filter bar.
• showDateInRelativeFormatShow date on the SFB like yesterday, tomorrow, and so on.
• enableLiveFiltershow/do not show go button on the smart filter bar.
• refreshIntervalInMinutesrefresh 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 in 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 datafieldForAnnotationannotation is not yet supported by CDS.

The card configuration for stack cards looks like the following:

"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

@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 Fieldgroup-Referencefacet with reference to configured field group id.

@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:

"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

Note

The navigation from the card items section is context sensitive, that is, if you select a particular item in the table/list card, this information will be sent to the navigating application as a selection variant.

All the properties related to the particular record will be sent. For example, your table card displays properties P1,P2,P3 as data, when you select the item, all the Odata properties P1,P2,P3….Pn will be sent as a selection variant (will be populated to the smart filter bar). If you would like only P1,P2,P3 to be passed, then use "addOataSelect:true (https://help.sap.com/viewer/468a97775123488ab3345a0c48cadd8f/7.52.3/en-US/530f9e6f66104d5888ade79b5cf417e0.html)

Navigation is possible from all cards and is supported in resizable layout as well.