Child pages
  • Open ODS View based on a ABAP CDS View
Skip to end of metadata
Go to start of metadata


As explained in the following note, it is not supported to use the generated view of an ABAP CDS View as source for an Open ODS View. 

  • 2673267  Consulting: Open ODS View or HANA DataSource based on ABAP CDS View

Instead you need to create a DataSource of ODP type 'ABAP Core Data Services' and then use this DataSource in the Open ODS View. See also

Example(BW75 System)

First we create a simple ABAP CDS view of type Cube with the annotation @Analytics.dataExtraction.enabled: true

When we use the feature Data Preview and set the filter Airline=AA, FlightConnection=0017 and Filghtdate =< 31.12.2018, the following result is displayed:


The Datasource has the ODP Context 'ABAP Core Data Services' and is based on our CDS view.

The data preview displays as expected (among others) the three data records:

Open ODS View

The key figure FlightPrice is associated with the InfoObject 0AMOUNT.


If we check the data with the help of transaction Listcube, the numbers are the same as in the data preview of the CDS view:


We also take a look at the so called adhoc query in RSRT and again check the data for the same combination of filters:

Query Result:

Technical Details and How to Analyse Problems

In case of issues it is often important to find out first the affected/relevant processing level. E.g when a query(based on such an OpenODS View) does not display the expected result the following main layers are involved

  • query(OLAP/Analytic Engine)
  • Provider: Open ODSView
  • DataSource
  • CDS View

Hence, as a first step it makes sense to check whether an issue can be replicated in transaction Listcube. If yes, we have excluded the query layer. Then it is recommended to set the following breakpoints in order find out whether the datasource is working as expected. In addition the report RODPS_REPL_TEST(see also can be used to check the data source.

We use the sample Open ODS View from above in the following in order to show some details.


When we run Listcube

the warning 'The data from the InfoProvider .. involved could not be checked' is issued

This is a general warning which means that Listcube does not check whether filters were applied correctly, see note 2115750 for further details. In our case, all filters are transferred correctly to the data source and we also get back only corresponding records:

If we had doubts that these data records are correct we could set the following breackpoint in the class CL_RSDS_ACCESS_ODP

Via a RFC call data is retrieved from the datasource(ODP). Here you can check whether e.g. all selections are handed over as expected. Unfortunately the data set returned by the datasource has to be converted in order to bring is in a readable form. This is done a bit later(some F6 steps):

The data is as expected. In case some issue is detected on this level, you can then use the report RODPS_REPL_TEST for further checks and also take a look at the SQL statement accessing the CDS view:

ST05 Trace


The report RODPS_REPL_TEST(see also Replication test with RODPS_REPL_TEST) can be sued the check the data of a ODP datasource. You can restrict the data by setting filters and define the requested fileds:

With this selection we only check one record of our test data set:

  • No labels