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 (and o_tx_range )
  4. Set a breakpoint in method READ (LC_RSDRI_INFOPROV) and check the content of table o_t_range
  5. Check the data returned by the method READ: <l_t_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>

Comments

  • 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 data records returned from the SourceCube (point 5: method READ, CL_RSDRI_INFOPROV), but the internal table e_t_data (point 6: 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 start 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. During the analysis you notice that the internal table o_t_range (point 4) is empty and 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 (point 3) 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 method READ already transferres wrong data. In such a case it makes sense to use transaction LISTCUBE (use the same selections as given in o_t_range !) for the SourceProvider. It should be possible to replicate the issue in LISTCUBE, this simplifies the analysis a lot. The same procedure is recommened when there is an error message transferred from the method READ.
  • Local selections are stored in the table o_tx_range when calling the function RSOA_VCUBE_READ_REMOTE_DATA. Since a RemoteCube 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

Summary 

 

Common Issues

Basically there are two 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, probaly routines are used, see notes
    • 967798 – Selection conditions are ignored by Virtual Providers
    • 532778 - Virtual Cubes and Navigation Attributes
  • If the query does not display the expected results: start at point 5 and check the data transferred from the method READ:
    • if data is as expected - check all further levels discussed above, in particular the transformation and start/end routines (right part of flow chart, Example I)
    • if data is already wrong - use transaction LISTCUBE for further checks (Example III)

Example

 

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

 

The query has two global filters

and 2 restricted Key Figures

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 are global filters for the infoobject STPE_MAT and the navigation attribute STPE_C1__0COUNTRY and 2 local restrictions regarding STPE_CUST (see Query Definition).

Interface DataManger / RSOA_VCUBE_READ_REMOTE_DATA (Point 3)

 

Since the cube has the setting 'Derive Sel. Conditions from Navigation Attribute' (SVTRANSFSEL) active, the selection conditions for the navigation attribute were transformed into selection conditions of the attribute-carrying characteristic STPE_C1.

Read data from SourceCube: method READ (LC_RSDRI_INFOPROV) (POINT 4)

 

You can see that the superset of the two local selections (STPE_CUST = C001 - C003)) is passed on to the SourceCube.

Check returned by the method READ: <l_t_data> (Point 5)

 

Check data transferred by the function RSOA_VCUBE_READ_REMOTE_DATA to the 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____50525 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=50525. 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).

data transferred from the DataManger to the OLAP Engine (Point 7)

 

 

 

 

  • No labels