Selection of source in the new GL MultiProvider

Introduction BI Content comes with many MultiProviders which combine a Basis Cube and a Virtual Cube.  A Basis Cube is one where data is stored physically in the BW data warehouse whereas a Virtual Cube is a virtual (as opposed to real) construct which extracts data from other sources and presents the data as if it were a cube.  An example of these MultiProviders is 0FIGL_M20 which comprises the Basis Cube 0FIGL_C20 and the Remote Cube 0FIGL_R20.

Delivered with BI Content are Queries which allows the user to choose the cubes from which the data is to be reported.

Fig 1 Query Value Selection

Constituent Cubes
0FIGL_C20 contains GL balances which have been copied/replicated to BW through the standard ETL.

0FIGL_R20 is a Virtual Provider which accesses the data through DataSources in a SAP ECC system and uses transformation like a Basis Cube.  Other types of Virtual Providers use BAPIs or Function Modules to directly access source data.

In addition to the above cubes, the multiprovider also includes an InfoObject 0ACCESSTP.  The purpose of the existence of this InfoObject in the MultiProvider is to provide the ability to select between the above two sources. 

Fig 2 MultiProvider

Variables in the Queries
The delivered queries 0FIGL_M20_Q0001 uses the InfoObject 0ACCESSTP as a Characteristic Restriction to allow the user to select between the two cubes.  The options are
# System Proposal
C Access to Replicated Data
R Direct Access to Operative Data

The selected value is then used to populate the variable 0P_INFOPROV_SREP with the technical name of the source InfoProvider.  The InfoObject 0INFOPROV, for which 0P_INFOPROV_SREP is a variable, is automatically included when a MultiProvider is constructed.  When used as a characteristic restriction, this enables the Query to only execute one part of the subquery, ie either the Basis Cube or the Virtual Cube.  This allows the MultiProvider query to run more efficiently.

The logic to populate the variable 0P_INFOPROV_SREP is in the ABAP function (SAP exit) RSVAREXIT_0P_INFOPROV_SREP.  The logic goes something like this :
if accesstype = C
  infoprovider = 0FIGL_C20
else
  infoprovider = 0FIGL_R20

 Fig 3 Dataflow

BEx variables SAP exits

Variables
BEx variables are parameters of a query which are filled with values when the query is executed.  The assignment of values can be done by the user when prompted or automatically during run time by the system in exits.  They are implemented as ABAP functions which are called when the query is invoked.
Variables are defined as exits in its processing type in Query Designer while the logic behind it is coded in ABAP.

Fig 1 Query Designer

The technical name for the variable, which is a Query object, is shown as (2) above, while the processing type (3) signifies that this is implemented as an SAP Exit.

SAP exit
SAP exits are delivered as part of Business Content while Customer exits are specified by the customer.  Searching for sap customer exit variable in a search engine should turn up various articles and documents on how to create a new customer exit.
The ABAP function name for SAP exits is formed by concatenating RSVAREXIT_ with the technical name of the exit.  For instance, the function name for the variable 0P_GL_ACCTP is RSVAREXIT_0P_GL_ACCTP.

The list of all variables with their processing type can also be found in table RSZGLOBV.

Code stepthrough
To understand or to step through the exit function, first open the function in an SAP ABAP session using transaction SE37.  Then create an External Breakpoint at the first line of code in the function module.  Remember to create the breakpoint using the login id as in the query.  When the query is run, processing will stop in the ABAP debugger.

 

Fig 2 Function Editor

You can now step through the code line by line.