If you define a Hana Composite Provider (HCPR) and activate some navigation attributes, the following warning might be displayed:
In the following the meaning of this warning message is discussed with the help of a simple example. The main points are
See also
Example
Our sample HCPR contains two Partproviders (combined with Union), one cube and one DSO:
For the charateristic STPE_C1, the navigation attribute STPE_C1__0COUNTRY is active.
After activation the following warning is displayed in the HANA studio:
Indeed, this navigation attribute is not active for the partproviders STPEDBIF9 and STPEDSO4:
This missing setting has consequences for the query runtime. Our simple test query has only the filter STPE_C1__0COUNTRY = AR and 'Customer' and some basic key figures in the drilldown. Only 2 rows are displayed (so the filter is very selective!)
In order to get the runtime statistic displayed we run the query in RSRT and use the following debug functions:
Statistic Data:
On the tab 'Aggregation Layer' we can see that two data records are transferred to the OLAP Engine, but on the tab 'HANA Calculation Engine Layer' we can see that the data base had to process intermediate result sets with 4177 and 102 rows:
The reason for this is that the filter STPE_C1__0COUNTRY = AR is not applied on the partproviders but on a intermediate result set which contains the data of these providers without the filter condition of the navigation attribute. If we use the debug function 'Display SAP Hana Query', the following definition of an Calculation Scenario is displayed:
This calculation scenario (with the join of the X-table with the union of the partproviders) is only necessary when navigation attributes are not active for the partproviders of the type Infocube and DSO. Then the following trex statement finally retrieves the data via the calculation scenario.
The restriction 1techprov_sid=62583 means that only one partprovider with the internal sid=62583 is accessed with this statement. In our case the HCPR has two partptoviders (one cube and one DSO combined with a Union)) and hence the procedure from above is done for both providers separately.
If we activate this navigation attribute for both providers, the query processing can be simplified and calculation scenarios with Joins aren't necessary any longer!
runtime statistics:
So, the intermediate result sets contain only one row in contrast to above where we had 4177 and 102 rows! This was just a very simple example with providers which don't contain much data, in a more realistic example the effect can be really big!