How to Implement a VirtualProvider with Function Module

How to Implement a VirtualProvider with Function Module

Applies to: SAP BI. For more information, visit the Business Intelligence homepage.

Summary This article explains how to use the BW VirtualProvider with Function Module to query a local database table. It uses an example of querying the TCURR table to display the currency exchange rate that is applicable at BW query runtime.

Author: Andrew Jabbitt

Company: Farscope Associates Limited

Created on: 01 October 2008

Author Bio Andrew Jabbitt is an independent BW Consultant currently engaged in the Oil and Gas industry and who has previously worked for:

• SAP, as the head of BW training delivery at SAP UK, and

• various clients in the Retail and Logistics sectors

Andrew has a broad and deep understanding of most aspects of SAP BI, including ABAP enhancements, Web Dynpro for ABAP (WDA), Business Server Pages (BSP) and general SAP BI development.

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 1

https://www.sdn.sap.com/irj/sdn/nw-bi


Table of Contents Business Scenario ..............................................................................................................................................3 Background Information......................................................................................................................................3

General ...........................................................................................................................................................3 VirtualProvider with BAPI................................................................................................................................3 Prerequisite knowledge...................................................................................................................................3

Step-by-step Procedure......................................................................................................................................4 Step 1 - Create a BW InfoProvider (with Function Module)............................................................................4 Step 2 - Create the Function Module ( ... the daddy!).....................................................................................6 Step 3 - Create a Query..................................................................................................................................9

Appendix...........................................................................................................................................................10 Function Module logic for BW VirtualProviders ............................................................................................10 Currency Translation Type (excerpt from SAP Help Portal) .........................................................................11 Function Module and Class Documentation .................................................................................................13

VirtualProviders with Function Modules .....................................................................................................................13 FU BAPI_INFOCUBE_READ_REMOTE_DATA........................................................................................................17 CL_RSDRV_REMOTE_IPROV_SRV ........................................................................................................................20

Related Content................................................................................................................................................22 Disclaimer and Liability Notice..........................................................................................................................23



Business Scenario Recently I experienced a scenario where a client relied on the BEx Analyzer Currency Conversion logic to convert query values from their original currency to a currency chosen by the user at query runtime.

However when this was deployed the client started getting a lot of questions about what currency exchange rate was being used.

After trying to explain SAP's quite complex Currency Translation Type logic (... and failing on several occasions!) we decided to explore a solution that would automatically query the TCURR table and show the exchange rate that applied on any given date to the end user whenever they wanted to know.

Background Information

General

In order to satisfy this requirement I decided to employ a BW VirtualProvider (with Function Module) to read Table: TCURR at query runtime.

This decision meant that we would have an ordinary BW query and therefore complete integration with the BEx front-end tools, an InfoProvider that was always in synch with the TCURR table without the need for loading and managing data and the coding freedom of a BW Function Module. Brilliant ... then I read the SAP Help documentation, uh oh!

VirtualProvider with BAPI

Note that I have chosen to employ the 'VirtualProvider with Function Module' option and not the equivalent 'VirtualProvider with BAPI' option because the table I want to query is local and not external to my BW system. Note further however that real time querying of data that is external to your BW system is also possible through BW VirtualProviders - and this is very good for reconciling data.

Prerequisite knowledge

I am by no means a hard-core ABAP programmer, but I can get my way around BW user exits. If you can do the same then you should be able to follow the steps I explain in the next section. If not, simply hand this paper to your friendly, local ABAPer.

Finally, I know enough about BW to know that I need to use ABAP in BW, if you have not yet had this realisation stop reading now and avoid the pain.



Step-by-step Procedure This is a relatively easy process that consists of three steps:

1. Create a BW VirtualProvider (with Function Module) to meet your reporting requirements

2. Create the Function Module

3. Create a Query

Step 2 above is the daddy!

Step 1 - Create a BW InfoProvider (with Function Module)

Find an appropriate InfoArea and right-click, select Create VirtualProvider from the context menu.

Give your InfoProvider a suitable technical name and description.

Ensure you select the Based on Function Module radio button, and click on the Details button



Fill in the name of the Function Module. See the next step for more detail on how to build the Function Module logic.

The flags on this window determine the details of the interface to the Function Module. Depending on which ones you select different parameters are written to the BW VirtualProvider interface for this InfoProvider.

For more information go to the SAP Documentation, which I have conveniently summarised in the appendix.

Finally design the VirtualProvider as you would for any Basic InfoProvider:

Add Characteristics

In my example I am adding the components of the Currency Translation Types so that my users can query TCURR effectively:

0CALDAY

ZCURR_FRM

ZCURR_TO

0RTYPE

Add Key Figures:

I have added a key figure to hold the Exchange Rate:

ZEXCHG_RT

See Appendix for details of how Currency Translation Types are defined in SAP BW



Step 2 - Create the Function Module ( ... the daddy!)

Right now that that is done let's move onto the really interesting bit: writing the Function Module to access the data.

The first thing to note is that we should copy the example function module:

• BAPI_INFOCUBE_READ_REMOTE_DATA

I went a step further and copied the function group: RSDRI.

Then, go to the Documentation of the above Function Module click on the link to the CL_RSDRV_REMOTE_IPROV_SRV class and copy the example code which you'll find at the end (how I know this is unknown even to me).

I have kindly copied this code into the appendix.



Modify the code to meet your requirements. My changes were to:

• Include a reference to 'TCURR';

• Add references to each of the relevant InfoObjects in my VirtualProvider.

The form: 'build_mapping_table' maps each of the InfoObjects onto the fields in the source table (TCURR)

It may be that your InfoObjects don't match the data elements of the field tables they are mapped to. I had this problem with 0CALDAY.

You have a choice to build a new InfoObject that uses the same Data Element, or you could modify the code to ensure the data stored in the source table is translated into an appropriate format for reporting.

I chose the second option as I wanted to use 0CALDAY and take advantage of the user's knowledge of that InfoObject.



Notice that the Function Module creates an object with a Type Ref of:

• CL_RSDRV_REMOTE_IPROV_SRV

We also call a method of that object (open_cursor) to select the data and another method (fetch_pack_data) to get the data.

In TCURR the field 'GDATU' uses the DATUM_INV domain which uses the INVDT conversion routine. INVDT converts dates in the format YYYYMMDD using the Nines Complement logic which makes the dates easier to add and subtract (I don't understand it fully either, but there is a Wikipedia page on Complements).

Nevertheless this use of INVDT for the field 'GDATU' means we have to undo this logic so that 0CALDAY presents properly in the front-end. I do this after I read the data from the database and before I send the data to the BW OLAP Processor (through the FM).

I decided to create a 'Z' copy of the class: CL_RSDRV_REMOTE_IPROV_SRV because I want to change the code in the Methods.

The method alongside is 'pack_data' which prepares the data for the OLAP Processor.

Notice the addition I made after the comment * Account for GDATU data format. This simply calls the Conversion exit for INVDT to return the data to a date format that 0CALDAY can use.



Step 3 - Create a Query

Finally create a standard BW Query on the VirtualProvider to query the data in Table: TCURR.

Define a query that meets your requirements

An interesting trend for the GBP/USD exchange rate ...!



Appendix

Function Module logic for BW VirtualProviders

FUNCTION ZRSDRV_RC1. *"----------------------------------------------------------------------*" *"Local Interface: *" IMPORTING *" VALUE(INFOCUBE) TYPE BAPI6200-INFOCUBE *" VALUE(KEYDATE) TYPE BAPI6200-KEYDATE OPTIONAL *" EXPORTING *" VALUE(RETURN) TYPE BAPIRET2 *" TABLES *" SELECTION STRUCTURE BAPI6200SL *" CHARACTERISTICS STRUCTURE BAPI6200FD *" KEYFIGURES STRUCTURE BAPI6200FD *" DATA STRUCTURE BAPI6100DA *" EXCEPTIONS *" COMMUNICATION_FAILURE *" SYSTEM_FAILURE *"---------------------------------------------------------------------- DATA: l_r_srv TYPE ref to CL_RSDRV_REMOTE_IPROV_SRV, l_th_mapping TYPE CL_RSDRV_REMOTE_IPROV_SRV=>TN_TH_IOBJ_FLD_MAPPING. break-point ID ZRSDRV_RC1. perform build_mapping_table changing l_th_mapping. create object l_r_srv exporting i_tablnm = 'ZRSDRVRC1' i_th_iobj_fld_mapping = l_th_mapping. l_r_srv->open_cursor( i_t_characteristics = characteristics[] i_t_keyfigures = keyfigures[] i_t_selection = selection[] ). l_r_srv->fetch_pack_data( importing e_t_data = data[] ). return-type = 'S'. ENDFUNCTION. *&--------------------------------------------------------------------* < *& Form build_mapping_table *&--------------------------------------------------------------------* < Form build_mapping_table changing c_th_mapping TYPE CL_RSDRV_EXTERNAL_IPROV_SRV=>TN_TH_IOBJ_FLD_MAPPING. DATA: l_s_map TYPE CL_RSDRV_EXTERNAL_IPROV_SRV=>TN_S_IOBJ_FLD_MAPPING. l_s_map-iobjnm = '0CALDAY'. l_s_map-fldnm = 'CALDAY'. insert l_s_map into table c_th_mapping. * ...do the same with other infoobjects endform. "build_mapping_table



Currency Translation Type (excerpt from SAP Help Portal)

Definition

A translation type is a combination of different parameters that establish how the exchange rate for the translation is determined.

Structure

The parameters that determine the exchange rate are the source and target currencies, exchange rate type and the time reference for the translation.

To define a translation type you have to define the exchange rate type, the time reference, and how and when the inverse exchange rate is used. Entering the target currency is optional.

• Exchange rate type: The exchange rate type distinguishes between exchange rates that are valid in the same time frame, for example, the bid rate, ask rate or middle rate. The exchange rate types are stored in a central table (TCURV) and can by maintained in Customizing using BI Customizing Implementation Guide → General Settings → Currencies → Check Currency Types. Alternatively you can specify any variable that exists for InfoObject 0RTYPE.

• Inverse exchange rate: You can choose whether the inverse exchange rate is to be used for the translation type. If you choose translation with the inverse exchange rate, then the reverse exchange rate is used in the relevant translation from one currency to another. Translation using the inverse exchange rate is useful, for example, when values from the original documents have been translated before being saved in the data targets and you want to restore the original values.

You have maintained the following exchange rates: EUR → USD 0.940 USD → EUR 1.070 When translating from USD to EUR using the inverse exchange rate, a rate of 1/0.940 = 1.064 is used and not a rate of 1.070.



• Source currency: The source currency is the currency that is to be translated. You have the following options:

o The source currency is determined dynamically using the data record. This is always the case when you perform currency translation in the Business Explorer.

o The source currency is determined dynamically using a specified InfoObject (characteristic). During the data load process, the source currency can be determined either using the data record or a specified characteristic bearing master data (see example: Defining Target Currencies Using InfoObjects. Determining the source currency using an InfoObject is performed in the same way).

o You can use a fixed source currency in planning functions. Data records with the same currency key as the source currency are translated.

o You can specify any variable that exists for InfoObject 0CURRENCY. You can also use these options in planning functions.

• Target currency:

To determine the target currency, you have the following options: ...

o You can establish that the target currency be determined upon translation. In the Query Designer under the properties for the relevant key figure, you specify either a fixed target currency or a variable to determine the target currency.

o You can enter a fixed target currency (for example, ‘EUR’).

o You can specify any variable that exists for InfoObject 0CURRENCY.

o In the currency translation type, you can specify an InfoObject which is used to determine the target currency upon translation. In characteristic maintenance on the Tab Page: Business Explorer, you have to determine a currency attribute. For more information, see the example under Defining Target Currencies Using InfoObjects. If the Only Use in Transformation indicator is set, you can also enter InfoObjects that do not have a currency attribute set in InfoObject maintenance. InfoObjects that are entered here have to be available in the source and contain a currency as an attribute.

o You can specify an InfoSet: This is only necessary if you are determining the target currency using an InfoObject that exists in the InfoSet more than once. You enter the field alias so that the InfoObject can be specified uniquely.

• Time reference: The time reference for the currency translation can be either fixed or variable.

If the time reference is fixed, the time at which the exchange rate is determined is independent of the data. You have the following options:

o You can establish that the time reference be determined upon translation.

o You can select the current date.

o You can specify a fixed date as the key date.

o You can specify any variable that exists for InfoObject 0DATE.

o You can establish that the query key date be used. This is determined in the query settings.

If the time reference is variable, the time at which the exchange rate is determined is decided by a time characteristic value.

o A variable time reference can, for example, be determined using the end or start of a fiscal year or calendar year, a period and a month – or even to the exact day. The following standard time characteristics are available: 0FISCYEAR, 0FISCPER, 0CALYEAR, 0CALQUARTER, 0CALMONTH, 0CALWEEK and 0CALDAY.

o The time reference can also be determined using a customer-specific InfoObject of type date (for example, trading day). Note that this InfoObject has to have the same properties as the standard InfoObject selected in the variable time reference or must reference it.


http://help.sap.com/saphelp_nw70/helpdata/EN/5f/b6d837aeadf03ae10000009b38f889/frameset.htm�

http://help.sap.com/saphelp_nw70/helpdata/EN/5a/8c5842fc6d5849b7fae266961ed707/content.htm


http://help.sap.com/saphelp_nw70/helpdata/EN/5f/b6d837aeadf03ae10000009b38f889/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/EN/5f/b6d837aeadf03ae10000009b38f889/frameset.htm



o You can specify an InfoSet: This is only necessary if you are determining the target currency using an InfoObject that exists in the InfoSet more than once. You enter the field alias so that the InfoObject can be specified uniquely.

o In the Business Explorer, you can only set time variable currency translations in query

definition, and not for an executed query. See also Setting Variable Target Currency in the Query Designer.

o In the Time Adjustment field of type INT4, you can specify whole numbers with a +/- sign. o In the Time Adjustment from Variable field, you can specify formula variables (1FORMULA).

As these values of the variables may have to be whole numbers, they are rounded to whole numbers (integers) where necessary.

The time adjustment (regardless of whether it is fixed or variable) is always related to the InfoObject specified under Variable Time Reference.

Example of a time adjustment of -3:

The variable time reference is To the exact day and the InfoObject under Variable Time Reference is 0CALDAY. Instead of 07.11.2006, after the time adjustment, 04.11.2006 is used for the translation.

The variable time reference is End of Week and the InfoObject under Variable Time Reference is 0CALWEEK. Instead of 52.2004, the week 49.2004 is calculated and the end date is calculated from this.

Function Module and Class Documentation

VirtualProviders with Function Modules

Definition

A VirtualProvider with a user-defined function module that reads the data in the VirtualProvider for analysis and reporting purposes.

You have a number of options for defining the properties of the data source more precisely. According to these properties, the data manager provides various function module interfaces for converting the parameters and data. These interfaces have to be implemented outside the BI system.

Use

You use this VirtualProvider if you want to display data from non-BI data sources in BI without having to copy the dataset into the BI structures. The data can be local or remote. You can also use your own calculations to change the data before it is passed to the OLAP processor.

This function is used primarily in the SAP Strategic Enterprise Management (SEM) application.

In comparison to other VirtualProviders, this VirtualProvider is more generic. It offers more flexibility, but also requires a higher implementation effort.

Structure

You specify the type of the VirtualProvider when you create it. If you choose Based on Function Module as the type for your VirtualProvider, an extra Detail pushbutton appears on the interface. This pushbutton opens an additional dialog box, in which you define the services.

...

1. Enter the name of a function module that you want to use as the data source for the VirtualProvider. There are different default variants for the interface of this function module. One method for defining the correct variant, together with the description of the interfaces, is given at the end of this documentation.


http://help.sap.com/saphelp_nw70/helpdata/EN/08/81b98b95e911d4b2ca0050da4c74dc/content.htm

http://help.sap.com/saphelp_nw70/helpdata/EN/08/81b98b95e911d4b2ca0050da4c74dc/content.htm


2. You can choose options to support the selection conditions. You do this by selecting the Convert Restrictions option. These conversions only change the transfer table in the user-defined function module. The conversions do not change the result of the query because the restrictions that the function module does not process are checked later in the OLAP processor.

Options:

o No support: If this option is selected, no restrictions are passed to the function module.

o Global selection conditions only: If this option is selected, only global restrictions (FEMS = 0) are passed to the function module. Other restrictions (FEMS > 0) that are created, for example, by setting restrictions on columns in queries, are deleted.

o Hierarchies: If this option is switched on, the relevant InfoProvider supports hierarchy restrictions. This is only possible if the InfoProvider also supports SIDs.

o Do not transform selection conditions: If this option is switched on, all selection conditions are passed to the function module, without being converted first.

3. Pack RFC: This option packs the parameter tables in BAPI format before the function module is called and unpacks the data table that is returned by the function module after the call is performed. Since this option is only useful with a remote function call, you have to define a logical system that is used to determine the target system for the remote function call, if you select this option.

4. SID support: If the data source of the function module can process SIDs, you should select this option. If this is not possible, the characteristic values are read from the data source and the data manager determines the SIDs dynamically. In this case, wherever possible, restrictions that are applied to SID values are converted automatically into the corresponding restrictions for the characteristic values.

5. With navigation attributes: If this option is selected, navigation attributes and restrictions applied to navigation attributes are passed to the function module. If this option is not selected, the navigation attributes are read in the data manager once the user-defined function module has been executed. In this case, in the query, you need to have selected the characteristics that correspond to these attributes. Restrictions applied to the navigation attributes are not passed to the function module in this case.

6. Internal format (key figures): In SAP systems a separate format is often used to display currency key figures. The value in the internal format is different from the correct value in that the decimal places are shifted. You use the currency tables to determine the correct value for this internal representation. If this option is selected, the OLAP processor incorporates this conversion into the calculation.

7. Data quality settings

o Data is delivered immediately: If you do not select the Pack RFC option, the function module interface contains parameter i_th_sfc with a numeric column ORDERBY or SORT. If this figure is not initial, it indicates the required sorting sequence of the field in the result. Choose the Sorted data is delivered option if the VirtualProvider delivers the data in the specified sequence.

o “Exact” data is delivered: Choose the “Exact” data is delivered option, if the VirtualProvider always exactly observes all filters specified on the interface. In some cases, the VirtualProvider omits filters and returns a superset of the requested data.

Dependencies

If you use a remote function call, SID support has to be switched off and the hierarchy restrictions have to be expanded.

Different variants are allowed for the interface of the user-defined function module. These variants depend on the options you have chosen for the VirtualProvider:



o If Pack RFC is switched on, choose variant 1

o If SID Support is switched off, choose variant 2

o Otherwise, choose variant 3

Description of the Interfaces for User-Defined Function Modules

Variant 1:

This variant is the most general and the most straightforward. It is described in the documentation for function module BAPI_INFOCUBE_READ_REMOTE_DATA.

Variant 2:



Variant 3:

SAP advises against using this interface.

The interface is intended for internal use only and is only mentioned here for completeness.

Note that the structures used in the interface may be changed by SAP.



FU BAPI_INFOCUBE_READ_REMOTE_DATA

Short Text

BAPI for Reading Data from a Remote InfoCube

Functionality

Comment: It is recommended to read this documentation in conjunction with the function module documentation for the function module BAPI_INFOCUBE_READ_REMOTE_DATA.

The function module BAPI_INFOCUBE_READ_REMOTE_DATA implements either an InfoProvider with service that is called using RFC, or a general remote InfoProvider. This documentation provides an overview of the parameters of the function module.

InfoCube

Name of the InfoProvider

Key Date

Key date for data dependent on key date

Return

Status information returned for the function module

Selection

This table contains the restrictions the OLAP processor uses to request data from the virtual InfoProvider. The restrictions are structured as follows:

The table contains the field Expression. This expression is the highest outline level of the restrictions. If the InfoProvider can only process global restrictions, the value of the Expression field is always 0. Otherwise, the logical restrictions consist of

E0 AND ( E1 OR E2 OR E3 ... OR EN ),

where E0 corresponds to the global restrictions. Within the same expression, the restrictions are structured in the same way as an ABAP range table: restrictions for identical characteristics are linked logically with OR; restrictions for different characteristics are linked logically with AND.

Example:

Expression InfoObject Sign Option Low High

0 MATERIAL I EQ '4711'

0 MATERIAL I EQ '4712'

0 CUSTOMER I EQ 'CUST01'

0 CUSTOMER I BT 'CUST04' 'CUST06'

1 COLOR I EQ 'RED'

2 SIZE I EQ 'XXL'

2 SIZE I EQ 'XL'

2 SEX I EQ 'MALE'



The selection looks as follows in an open SQL condition:

( ( Material = '4711' OR Material = '4712' ) AND ( Customer = 'CUST01' OR Customer between 'CUST04' AND 'CUST06' ) ) AND ( ( COLOR = 'RED' ) OR ( (SIZE = 'XXL' OR SIZE = 'XL' ) AND ( SEX = 'MALE' ) ) )

Characteristics

This table contains a description of the requested characteristics along with their data types and decimal places. It also contains the offset and the length of the field in the return table.

Key Figures

This table has the same structure as the characteristics table and describes the key figures requested.

Data

This table returns the data.

To fill this table, the individual characteristics and key figures of a logical data record are written to a character field without separators and with the specified length and offset. If the character field (total length of all characteristics and key figures requested) is longer than 250 characters, when the data row is copied to the Data table, a break is made after each 250 characters, and the continuation field of the cut off row must be set to 'X'.

When the data is unpacked, the rows of the table are placed next to each other until a row is reached for which the continuation field has not been set. The values of the characteristics and key figures are then read from the logical data row with length and offset that was created in this way.

Example

The following characteristics and key figures are requested:

INFOOBJECT DATATYPE DECIMALS SIGN LENGTH OFFSET LOWERCASE

RSDRV_C01 CHAR 000000 6 0

RSDRV_C02 CHAR 000000 6 6

RSDRV_C03 NUMC 000000 3 12

RSDRV_C03__RSDRV_N01 CHAR 000000 6 15

RSDRV_C03__RSDRV_N02 CHAR 000000 6 21

0CALDAY DATS 000000 8 27

INFOOBJECT DATATYPE DECIMALS SIGN LENGTH OFFSET LOWERCASE

RSDRSKYF1 INT4 000000 X 11 35

RSDRSKYF2 DEC 000003 X 23 46



The Data result table looks as follows:

CONTINUATION DATA

C01_01C02_02102N01_02N02_1120010101 1 1.000

C01_01C02_02112N01_02N02_1220010101 1 1.000

C01_01C02_03102N01_02N02_1120020101 1 1.000

If the length of the data components was not 250 characters, but only 40 characters, each logical row would have to be cut off:

CONTINUATION DATA

X C01_01C02_02102N01_02N02_1120010101

1 1.000

X C01_01C02_02112N01_02N02_1220010101

1 1.000

X C01_01C02_03102N01_02N02_1120020101

1 1.000

For demonstration purposes, the spaces (Hex 20) are replaced with an asterisk (*').

CONTINUATION DATA

X C01_01C02_02102N01_02N02_1120010101******

*****1******************1.000

X C01_01C02_02112N01_02N02_1220010101******

*****1******************1.000

X C01_01C02_03102N01_02N02_1120020101******

*****1******************1.000

Further information

The class CL_RSDRV_REMOTE_IPROV_SRV contains services for implementing a BAPI-based InfoProvider that is based on a database table.

Parameters INFOCUBE KEYDATE RETURN SELECTION CHARACTERISTICS KEYFIGURES DATA

Exceptions

Function Group

RSDRI



CL_RSDRV_REMOTE_IPROV_SRV

Service Class for Remote InfoProvider

Functionality

This class helps with the implementation of a VirtualProvider (BAPI interface) based on any database table or view. Not all fields in the database table have to be assigned InfoObjects; not all InfoObjects of the InfoProvider have to have a counterpart in the table.

Use:

In the constructor, a model of the characteristics and key figures of the VirtualProvider is passed to the field names of the database table and the name of the table. Only the InfoObjects in the mapping table are incorporated when the SQL statement is generated.

If the SQL statement itself no longer has to be changed, you can use the open_cursor method, which builds the SQL statement.

The data can then be read using the fetch_pack_data method and packed in the RFC return format. Alternatively, this can also occur separately, in which case the data is fetched with the fetch_data method. In so doing, the data is entered to a table with the row type of the database table/view of the InfoProvider. The pack_data method packs the data in the RFC format.

Alternatively, you can assemble the modules of the SQL statement using the build_select_list and build_where_conditions methods. These modules can be changed to incorporate additional conditions that do not originate from the interface.

In this case, the reading of the data must be implemented by Open SQL itself; the implementation of the open_cursor and fetch_data methods can be used as examples.

The data can be changed as needed before it is returned if this is required by the implementation of the VirtualProvider.

Relationships

The CL_RSDRV_EXTERNAL_IPROV_SRV class contains services for local VirtualProviders without SID support.

Example

FUNCTION ZRSDRV_RC1. *"----------------------------------------------------------------------*" *"Local Interface: *" IMPORTING *" VALUE(INFOCUBE) TYPE BAPI6200-INFOCUBE *" VALUE(KEYDATE) TYPE BAPI6200-KEYDATE OPTIONAL *" EXPORTING *" VALUE(RETURN) TYPE BAPIRET2 *" TABLES *" SELECTION STRUCTURE BAPI6200SL *" CHARACTERISTICS STRUCTURE BAPI6200FD *" KEYFIGURES STRUCTURE BAPI6200FD *" DATA STRUCTURE BAPI6100DA *" EXCEPTIONS *" COMMUNICATION_FAILURE *" SYSTEM_FAILURE *"------------------------------------------------------------------- DATA: l_r_srv TYPE ref to CL_RSDRV_REMOTE_IPROV_SRV, l_th_mapping TYPE CL_RSDRV_REMOTE_IPROV_SRV=>TN_TH_IOBJ_FLD_MAPPING. break-point ID ZRSDRV_RC1.



perform build_mapping_table changing l_th_mapping. create object l_r_srv exporting i_tablnm = 'ZRSDRVRC1' i_th_iobj_fld_mapping = l_th_mapping. l_r_srv->open_cursor( i_t_characteristics = characteristics[] i_t_keyfigures = keyfigures[] i_t_selection = selection[] ). l_r_srv->fetch_pack_data( importing e_t_data = data[] ). return-type = 'S'. ENDFUNCTION. *&--------------------------------------------------------------------* < *& Form build_mapping_table *&--------------------------------------------------------------------* < Form build_mapping_table changing c_th_mapping TYPE CL_RSDRV_EXTERNAL_IPROV_SRV=>TN_TH_IOBJ_FLD_MAPPING. DATA: l_s_map TYPE CL_RSDRV_EXTERNAL_IPROV_SRV=>TN_S_IOBJ_FLD_MAPPING. l_s_map-iobjnm = '0CALDAY'. l_s_map-fldnm = 'CALDAY'. insert l_s_map into table c_th_mapping. * ...do the same with other infoobjects endform. "build_mapping_table

Note: In this example, there are two points to note:

• The types in the build_select_list and build_where_conditions modules correspond to the data types in the RFC module that were passed as TABLES parameters: characteristics, key figures, and selections.

• You can access public types of a class from outside the class using class name => type name.



Related Content SAP Library: VirtualProviders

SAP Library: Currency Translations

SDN Forum: VirtualProviders

For more information, visit the Business Intelligence homepage.


http://help.sap.com/saphelp_nw70/helpdata/en/e3/e60138fede083de10000009b38f8cf/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/EN/ec/076f3b6c980c3be10000000a11402f/frameset.htm

https://www.sdn.sap.com/irj/sdn/advancedsearch?query=virtualproviders&cat=sdn_all

https://www.sdn.sap.com/irj/sdn/nw-bi



Disclaimer and Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.

SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk.

SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.

How to Implement a VirtualProvider with Function Module

Documents

Transcript of How to Implement a VirtualProvider with Function Module