Analytics Annotations

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;
   };
   writeBack
   {
      className : String;
   };
 };

Usage

The analytic manager needs a star schema (multidimensional) and a query to consume the data. Most annotations for defining 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 analytical 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`	By specifying the data category, the developer can give directives and hints, for example, tell the analytic manager how to interpret individual entities. Scope: #VIEW Evaluation Runtime (Engine): Analytic query can be defined on top of CDS views using the `Analytics.dataCategory` annotation. Values:
	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, then 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 fact 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.query`	Query view classification. By tagging the CDS view, the developer can specify which views will be exposed to the analytic manager. These views must not be annotated with `Analytics.dataCategory = #NONE`. Scope: #VIEW Evaluation Runtime (Engine): Annotation related to analytic queries. This type of view is interpreted as an analytic query by the analytic manager and data is 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. Values:
	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.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). These views have to be annotated with `Analytics.dataCategory` (except the value `AGGREGATIONLEVEL`). Scope: #VIEW Evaluation Runtime (Engine): These views are exposed in replication scenarios. Values:
	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.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`	You can use this annotation to define an input-enabled analytic query. It can only be used in views with `Analytics.query: true`, and the view has to select data from a view which is annotated with `Analytics.dataCategory: #AGGREGATIONLEVEL`. Scope: #VIEW Evaluation Runtime (Engine): An input-enabled query provides writeback capabilities and can be used in planning scenarios. Values:
	Value	Description
	`true`	The view is enabled for planning. This is the default setting.
	`false`	The view is not enabled for planning.
`Analytics.writeBack.className`	Only relevant for `Analytics.dataCategory: #CUBE` or `Analytics.dataCategory: #FACT`. Scope: #VIEW Evaluation Runtime (Engine): 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. Values:
	Value	Description
	`className`as String	Name of an ABAP class, which implements the interface IF_RODPS_ODP_WRITEBACK. The class enables the analytic manager to write data to the view.

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,
...}