Analytics Annotations

Enable the analytic manager for multidimensional data consumption, performing data aggregation, and slicing and dicing data. BI frontends like Design Studio and Analysis Office can consume the data via the analytic manager.

Scope and Definition

@Scope:[#VIEW]
Annotation Analytics
 {
   dataCategory : String enum { DIMENSION; FACT; CUBE; AGGREGATIONLEVEL; };
   query : Boolean default true;
   hidden : Boolean default true;
   planning
   {
      enabled : Boolean default true;
   };
   dataExtraction
   {
      enabled : Boolean default true;
      delta :
      {
         byElement : elementRef;
         {
			name : RefToElement;
			maxDelayInSeconds : Integer default 1800;
         };
      };
   };
   writeBack
   {
      className : String;
   };
 };

Usage

The analytic manager needs a star schema (multidimensional) and a query to consume the data. Most annotations to define the star schema in different CDS views are specified in ObjectModel annotations. The Analytics annotations also specify the facts (center of the star schema), extraction capabilities for replicating data into further systems, and analytic query properties. A semantic distinction can be made in the Analytics annotations between annotations that are relevant for the InfoProvider (CUBE) level and annotations that are only relevant for analytic queries.

Annotation Meaning

Analytics.dataCategory

Analytic queries can be defined on top of CDS views using the Analytics.dataCategory annotation.

Scope: #VIEW

Evaluation Runtime (Engine): By specifying the data category, the developer can provide directives and hints, telling the analytic manager how to interpret individual entities for example.

Value Description
#DIMENSION Views representing master data should be annotated with ObjectModel.dataCategory: #DIMENSION. If you want to use one of these views for replication or for a query, you should also use Analytics.dataCategory: #DIMENSION.
#FACT This value indicates that the entity represents transactional data (center of star schema). Usually it contains the measures. Typically, these views are necessary for replication, therefore, they should not be joined with master data views.
#CUBE The #CUBE value (like #FACT) also represents factual data, but #CUBE does not have to be without redundancy. This means joins with master data are possible. Queries are usually built on top of #CUBE, where data is replicated from facts.
#AGGREGATIONLEVEL This value indicates a projection. For this kind of view, the analytic manager offers write-back functionality (planning functionality). Views in this category have to select from a view with dataCategory = #CUBE, which supports the annotation Analytics.writeBack.className. No associations are allowed, and elements cannot be renamed.

Analytics.dataExtraction.enabled

Application developers can use this annotation to mark views that are suitable for data replication (for example, delta capabilities must be provided for mass data).

Scope: #VIEW

Evaluation Runtime (Engine): Specifies which view will be exposed in replication scenarios.

Value Description
true The view is suitable for data replication. This is the default setting.
false The view is not suitable for data replication.

Analytics.dataExtraction.byElement.name

Application developers can enable the generic delta extraction with this annotation. This is the element that should be used for filtering during generic delta extraction. This element can either be a date (ABAP type DATS) or a UTC time stamp.

Scope: #VIEW

Evaluation Runtime (Engine): Specifies which view will be exposed in replication scenarios.

Value Description
elementName as String Name of an element that should be used for filtering during generic delta extraction.

Analytics.dataExtraction.byElement.maxDelayInSeconds

There is always a time delay between taking a UTC time stamp and the database commit. This annotation specifies the maximum possible delay in seconds.

Scope: #VIEW

Evaluation Runtime (Engine): Specifies which view will be exposed in replication scenarios.

Value Description
Integer Maximum number of seconds between taking the time stamp and the successful database commit. The default is 1800 seconds.

Analytics.hidden

You can use this flag to decide whether the entity should be visible to analytic clients.

Scope: #VIEW

Evaluation Runtime (Engine): Views with Analytics.query are not exposed in value help. Views with Analytics.dataCategory are not exposed in value help for the CDS query designer.

Values:

Value Description
true The view cannot be consumed by analytic clients. This is the default setting.
false The view can be consumed by analytic clients.

Analytics.planning.enabled

An input-enabled query provides writeback capabilities and can be used in planning scenarios.

Scope: #VIEW

Evaluation Runtime (Engine): Specifies which view will be interpreted as input-enabled analytic query by the analytic manager.

Value Description
true The view is enabled for planning. This is the default setting.
false The view is not enabled for planning.

Analytics.query

Query view classification.

Scope: #VIEW

Evaluation Runtime (Engine): By tagging the CDS view, the developer can specify which views will be exposed to the analytic manager. This type of view will be interpreted as an analytic query by the analytic manager.

Value Description
true The query view will be exposed to the analytic manager. This is the default setting.
false The query view will not be exposed to the analytic manager.

Analytics.writeBack.className

Views with Analytics.dataCategory: #AGGREGATIONLEVEL on top of this type of view can be used for planning scenarios. The ABAP class is used for saving the data, authorization checks and enqueuing.

Scope: #VIEW

Evaluation Runtime (Engine): Specifies which class enables the analytic manager to write data to the view.
Value Description
className as String Name of an ABAP class, which implements the interface IF_RODPS_ODP_WRITEBACK.

Examples

Example 1

Replication-enabled master data.

Example 2

Transactional data (fact).

Example 3

Use of $session variables, especially $session.system_date.

The system supports variables like $session.system_date for different use cases:

  • in cube parameters

  • in queries on time-dependent master data in where clauses

  • in paths to time-dependent attributes or texts

  • in restricted key figures