Page tree
Skip to end of metadata
Go to start of metadata


Technical Overview

The following flow chart diplays the most important processing layers of queries based on such virtual providers. When analyzing queries in RSRT(note 1591837 'How to analyze query results') , the mentioned ABAP Objects can be used to set propper breakpoints and check the relevant internal tables (see also note 1592982). This should help you to figure out fast which processing layer does not work as expected.

Step-by-Step Debugging Guide

  1. Simplify the query, in particular assure that the query only accesses the affected virtual provider (e.g. by setting a global filter for 0INFOPROV)
  2. Run query in RSRT and check which selections are transferred from the OLAP Engine to the DataManager. You can use the default breakpoint called OLAP Processor/DataManger(FILL_SP) and check the internal table
    1. BW74: <l_sx_rr>-seldr (p_r_rsdrc_read_olap->read)
    2. BW73: <l_sx_rr>-seldr  (function RSDRC_INFOPROV_READ_OLAP)
  3. Set breakpoint at function RSOA_VCUBE_READ_REMOTE_DATA and take a look at the internal table I_T_RANGE
    1. i_t_selections: restrictions transferred to the DataSource (can be used in RSA3)
    2. i_t_fields: requested fields (correspond to the characteristics in the drilldown)
  5. Set breakpoint at function RSUR_DATA_UNWRAP_RFC to check the data (table E_DATA) returned by the DataSource (RSAD_INFOCUBE_READ_REMOTE_DATA)
  6. Check the data transferred by the function RSOA_VCUBE_READ_REMOTE_DATA to the DataManager
    1. internal table e_t_data: the fields use internal IDs instead of the technical name of the infoobjects. E.g.
      1. S____005: SIDs for characteristic with ID=5: in the table /BI0/SIOBJNM you can look up the name of the object (select SID=5)
      2. K____005: Keys  for characteristic with ID=5:
      3. Z____049_SUM: Key Figure with ID=49:  in the table /BI0/SIOBJNM you can look up the name of the object (select SID=49)
  7. Check the data transferred from the DataManger to the OLAP Engine in the table <l_t_data>


  • Please note that the query might process more than one data package. Importing Parameters like e_end_of_data and  e_more_data are set to 'X' when there is no more data.
  • Example I: we assume that a query does not display any data. During the analysis it turns out that there are some data records returned from the DataSource (RSUR_DATA_UNWRAP_RFC ) but the internal table e_t_data (RSOA_VCUBE_READ_REMOTE_DATA ) is empty. By looking at the flow chart above you can see that between these two layers the transformation (plus strat and end routine) is processed. Hence, in this case the next step would be to have a closer look at the transformation and routines. If it is necessary to set a breakpoint in the routines you need to do it in the 'generated programm' as described in DTP Simulation.
  • Example II: a query runs into a memory dump in the source system (the extractor of the datasource delivers too much data). During the analysis you notice that the internal table i_t_selections is empty when the function RSAD_INFOCUBE_READ_REMOTE_DATA is called. This explains why the system runs out of memory. Hence you need to check between which processing layers the restrictions dissapear. Let's assume that they are still there when RSOA_VCUBE_READ_REMOTE_DATA is called. Then you know that they are removed (see again the flow chart) when the inverse routines/transformation is processsed. See note 1592982 'VC: Query selections not passed to virtual cube' for further details.
  • Example III: a query does not deliver the expected result. During the Analysis you notice that the function RSAD_INFOCUBE_READ_REMOTE_DATA already transferres wrong data. In such a case it makes sense to run the transaction RSA3 (Extractor Checker; use the same selections!) for the DataSource in the source system. It should be possible to replicate the issue in RSA3, this simplifies the analysis a lot. The same procedure is recommened when there is an error message transferred from function RSAD_INFOCUBE_READ_REMOTE_DATA.
  • Local selections are stored in the table o_tx_range when calling the function RSOA_VCUBE_READ_REMOTE_DATA. Since a Datasource cannot handle local restrictions, the system tries to determine a superset which can be added to the global selections. If this is not possible, then all local restrictions are removed.
  • Always check whether Infoprovider settings (see screenshot below) are as required
    1. Do Not Transform Selection Conditions: If this option is selected, all selections are passed to the function module RSOA_VCUBE_READ_REMOTE_DATA, without being converted first. You can use the F1 help in RSDCUBE to get more information displayed.
    2. Derive Selections Conditions from Attributes: This flag indicates whether selection conditions for navigation attributes are to be transformed into selection conditions of the attribute-carrying characteristic. You can use the F1 help in RSDCUBE to get more information displayed
  • Sometimes it is convenient to check the provider settings in the corresponding administration table RSDCUBE – you can use F1 help to get an explanation about the setting!

    1. NOTRANSFRESTR –> Do not Transform Selection Condition
    2. SVTRANSFSEL  -  Derive Sel. Conditions from Navigation Attribute

Important Facts

Customer exits are not executed

If the extractor is used by a direct access DTP, then the customer exits(RSAP0001, exit_saplrsap_001, exit_saplrsap_002 and exit_saplrsap_004) for the extractor are not executed. For additional details, please check the F1 help of the "Data Extraction" point of the DTP. This includes the following information:


For all source systems apart from the ODP source system, the data source is accessed in "direct access mode". This has certain implications, especially when extracting from SAPI systems:

  • The data is extracted synchronously. This places special requirements on main memory, especially in the remote system.
  • The SAPI extractors might behave differently than for asynchronous loading since they are informed by the direct access.
  • No SAPI customer enhancements are processed. Fields that were added to the DataSource with append technology are left empty. Exits RSAP0001, exit_saplrsap_001, exit_saplrsap_002 and exit_saplrsap_004 are not executed.
  • If errors occur during processing, you need to extract the data again in BW because the PSA is not available in the buffer. This means that it is not possible to create a delta.
  • The filter in the DTP only contains fields that are allowed as selection fields by the DataSource. If a PSA is available, you can use all the fields for filtering in the DTP.


In case you need a field, which is filled via customer exit, then this should be done via an ODP source system instead of a SAPI one. If the creation of an ODP source system is not possible, then you have to first load the data up to the PSA and then move thedata to the corresponding providers.



Common Issues

Basically there are 2 types of problems

  • If the query allocates too much memory or the query performnace is very bad: check whether all query restrictions are transferred as expected to the Source of the RemoteProvider (left part of the flow chart; Example II).
    • If not, probably routines are used, see notes
      • 1486659 Inverse Routines in Transformation for Virtual Providers , SPO,....
      • 967798   Selection conditions are ignored by Virtual Providers
      • 2154271 VC: Memory and Compression dumps when extracting data from VC with Direct Access DTP
      • 532778   Virtual Cubes and Navigation Attributes
    • If yes,  
      • it might be the case that the DataSource (extractor) isn't able to handle the transferred selections. You can use the extractor checker (TA RSA3) in the source system to check this.
      • it can be that the query simply retrieves too much data from the data source. Virtual Cubes are not intended to transfer mass data(there is no package wise reading for 'direct access' and the complete resultset requested needs to be processed at once)! See note 2154271. You need to set further rstrictions in the Query.
  • If the query does not display the expected results: start at point 4 and check the data transferred from the function RSAD_INFOCUBE_READ_REMOTE_DATA:
    • if data is as expected - check all further levels discussed above, in particular the transformation and the start/end routine (right part of flow chart, Example I)
    • if data is already wrong - use the extractor checker (TA RSA3) in the source system for further checks (Example III)


Query is defined on a virtual provider with the following properties (Source = DataSource):

The query has one global filter and 2 restricted Key Figures

We now run the query in RSRT and follow the debugging guide from above:

Interface OLAP Engine / DataManager (Point 2)

The OLAP Engine uses internally the field FEMS to handle correctly local (FEMS>0) and global restrictions(FEMS=0). It is basically the BW-internal representation of the filter conditions for a restricted keyfigure, e.g. see the blog   FEMS and BW on HANA. In our case there is one global filter for the infoobject STPE_CUST and 2 local restrictions regarding 0Calmonth (see Query Definition).

Interface DataManger / RSOA_VCUBE_READ_REMOTE_DATA (Point 3)

All restrictions are passed on to the function RSOA_VCUBE_READ_REMOTE_DATA.

RFC call of function RSAD_INFOCUBE_READ_REMOTE_DATA (Point 4)

set the following breakpoint in function RSOA_DSOURCE_READ_REMOTE_DATA: 

You can see that the superset of the two local selections (CALMONTH) is passed on to the DataSource.

call stack:

Data returned from DataSource: function RSUR_DATA_UNWRAP_RFC (Point 5)


Data transferred from function RSOA_VCUBE_READ_REMOTE_DATA to DataManager (Point 6)

As mentioned above, the internal table e_t_data does not use the technical names of the infoobjects but the so called CHANMIDs. K____005 means that in this colum you can find the keys for the characteristic with the CHANMID=5. In the table /BI0/SIOBJNM you can look up the name of the object by selecting SID=5 (refers to 0CALMONTH). The CHANMID is also displayed in the debugger, e.g. you can find it in the internal tables p_th_isfc (characteristics) and p_th_isfk (key figures).



  • No labels