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`. Tip Typical dimensions are material view, customer view etc.
	`#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. Note This view must be annotated with `Analytics.dataCategory` (except the value `AGGREGATIONLEVEL`).
	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. Note This view must be annotated with `Analytics.query: true`.
	Value	Description
	`true`	The view is enabled for planning. This is the default setting. Note The view has to select data from a view, which is annotated with `Analytics.dataCategory: #AGGREGATIONLEVEL`.
	`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. Note This view must not be annotated with `Analytics.dataCategory = #NONE`.
	Value	Description
	`true`	The query view will be exposed to the analytic manager. This is the default setting. Note Data will be selected from the view specified in the `from` clause. The view of the `from` clause has to be annotated with the `Analytics.dataCategory` as `#DIMENSION`, `#CUBE` or `#AGGREGATIONLEVEL`, and the DCL has to be assigned to the view of the `from` clause.
	`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. Note Only relevant if `Analytics.dataCategory: #CUBE` or `Analytics.dataCategory: #FACT`.
	Value	Description
	`className` as String	Name of an ABAP class, which implements the interface IF_RODPS_ODP_WRITEBACK.

Examples

Example 1

Example for replication-enabled master data.

Sample Code

@EndUserText.label: 'EPM Demo: Employee'
@Analytics:{ dataCategory: #DIMENSION , dataExtraction.enabled: true }
//@VDM.viewType: #BASIC
@AccessControl.authorizationCheck: #CHECK
@ObjectModel.representativeKey: 'EmployeeUUID'
@AbapCatalog.sqlViewName: 'SEPM_IEMPLOYEE'
define view SEPM_I_Employee as
  select from snwd_employees

association [0..1] to SEPM_I_Company               as _Company               on $projection.CompanyUUID        = _Company.CompanyUUID  
...

{
  key snwd_employees.node_key      as EmployeeUUID,
  @ObjectModel.foreignKey.association: '_Company'  
  snwd_employees.parent_key        as CompanyUUID,
...}

Example 2

Example for transactional data (fact).

Sample Code

@EndUserText.label: 'EPM Demo: Sales Order Item with Addtl. Data (private view)'
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
@AbapCatalog.sqlViewName: 'SEPM_PSOIC'

define view SEPM_P_SalesOrderItemCube
  with parameters
    P_DisplayCurrency : snwd_curr_code      //for currency conversion, TODO: data element with better description

  as select from SEPM_I_SalesOrderItem

  association [0..1] to SEPM_I_SalesOrder_E          as _SalesOrder_E      on  $projection.salesorder      = _SalesOrder_E.SalesOrder
...
  
{
                                                     @ObjectModel.foreignKey.association: '_SalesOrder_E'
  key _SalesOrder.SalesOrder,
                 _SalesOrder_E,
...}