/GRC
Create your own customized retractor for transferring data to SAP ERP Central Component using SAP NetWeaver BI Integrated Planning. Sample documents are included.
Key Concept
A retractor is an SAP NetWeaver BI process to extract data and load it into SAP ERP (and R/3). Standard retractors are available for Profitability Analysis (CO-PA), Budget Control System (BCS), Cost Center Accounting (CCA), and Project Planning and Investment Management (PS/IM).
In the development of planning solutions, you often need to send planned or calculated data to SAP ERP. The target for this data may be SAP standard tables or custom tables. SAP provides some standard retractors, but does not provide a framework to retract data outside of these areas to your SAP ERP or R/3 system.
I’ll describe how to use a custom planning type to extract, package, transfer, and load data to your SAP ERP system. I’ll use the example of retracting Profit Center Accounting (PCA) plan totals from SAP NetWeaver BI 7.0 to SAP ERP.
Implementation of Retractor Planning Type
I provide three associated documents that you can use to implement the planning type and associated objects. Download these three associated documents by clicking the following links:
Technically, the Word document is all you need, but using the NUGG and IOBJ files simplifies the implementation of the planning type.
This makes a new planning type in the BI Modeler (transaction RSPLAN) available to you (Figure 1). By creating this planning type, you make it possible to create a planning function to retract data.

Figure 1
Custom retractor planning type in SAP NetWeaver BI Modeler
How the Custom Retractor Works
Figure 2 is a schematic of how the various components interact. The custom retractor is master data driven and works by defining the configuration in the retractor master data InfoObjects. By using transactions RSA1 or RSD1 you create the master data entries:
- Define the retractor type by creating an entry in InfoObject ZRET_TYPE
- Define the retractor parameters by creating entries in InfoObject ZRET_PAR
- Define the retractor mappings from the InfoProvider to the data structure by creating entries in InfoObject ZRET_MAP
After you enter this data, you can create a planning function to extract the desired data from SAP NetWeaver BI and then transfer it to SAP ERP for loading into your system.

Figure 2
Schematic of custom retractor component
Scenario — Loading Plan PCA Data (Totals Only)
After you complete a plan cycle, you need to extract the forecasted months of PCA plan data from SAP NetWeaver BI and load it into SAP ERP for use in reports. The plan data is selected from the InfoProvider and mapped to a structure. This is then sent to SAP ERP for loading into the GLPCT data structure (totals table).
Note
For complex retraction when you need more than one structure, you have to stage the data into temporary database tables in SAP ERP. When the last structure is loaded, it can then be placed into SAP ERP permanent tables by calling a POST_DATA_LOAD function module.
Define the Retractor Definitions
In this example, plan data from SAP NetWeaver BI is extracted from the PCA plan InfoProvider and mapped to a structure. It is then transferred to SAP ERP for loading into GLPCT.
To create the custom retractor, you have to enter the master data definitions. The first step is to define the specific generic extractor you are creating. In Figure 3, you can see an entry in InfoObject ZRET_TYPE.

Figure 3
Defined retractor type in InfoObject ZRET_TYPE
After you identify the retractor, you create common structures in SAP NetWeaver BI and SAP ERP. Do this via ABAP Data Dictionary transaction SE11. Figure 4 shows a section of the common structure. It contains all the fields for GLPCT. (Full definitions are in the downloadable Word document, “Implementation of Custom Retractor Planning Type.”)

Figure 4
Example of the SAP NetWeaver BI GLPCT data structure
The InfoProvider and data structure have different definitions. Therefore, you need a set of mapping rules to map the InfoProvider to the data structure. By creating the mapping entries in the InfoObject ZRET_MAP, you can map the characteristics of an InfoProvider to the fields of the data structure. Figure 5 shows the example of this mapping. You can also insert constants where no mapping exists or if you need to overwrite the InfoProvider value.

Figure 5
Mapping definitions in InfoObject ZRET_MAP
Define SAP ERP Data Load Function Module
Because a generic retractor is specific to a company’s requirements, you need to create a custom function module in SAP ERP to load the data. The implementation details could be as simple as loading the data into a transparent table, or as complex as my scenario. The development of this retraction function module requires some ABAP competency, which you cannot avoid due to the custom nature of the retraction development.
Figure 6 provides a basic code sample to detail the code framework. The full details of the data load and post data load function modules are described in downloadable noted as the start of the article. The complete code for the data load function module to load into GLPCT is detailed in the associated download.
FUNCTION zbw_glpct_retraction. *”---------------------------------------- --------------------- *”*”Local interface: *” IMPORTING *” VALU E(I_TEST_RUN) TYPE CHAR1 *” EXPORTING *” VALUE (E_T_MSG) TYPE BAPIRET2_T *” CHANGING *” VALUE (I_T_DATA) TYPE ZBW_GLPCT_RETRACTOR_T *”------------------------------------------------------- ------
DATA: l_bapiret2 TYPE bapiret2,
l_count TYPE string.
*
* Build Start Message.
*
DESCRIBE TABLE i_t_data LINES l_count.
l_bapiret2- id = ‘RSPLF’.
l_bapiret2-number = ‘099’.
l_bapiret2- type = ‘I’.
l_bapiret2-message_v1 = ‘Start of Remote Function Module’.
l_bapiret2-message_v2 = ‘ZBW_GLPCT_RETRACTION’.
l_bapiret2-message_v3 = ‘Number of Records Received = ‘.
l_bapiret2-message_v4 = l_count.
APPEND l_bapiret2 TO e_t_msg.
|
Figure 6 |
Code example of a DATA_LOAD function module |
|
Define Retractor Variables in BI Master Data
As there is no limit to the number of generic retractors, the parameters of the custom retractor can vary. For this reason, the parameters are stored in master data. This enables the re-use of components previously built and overcomes system differences in an SAP landscape.
These parameters are defined in InfoObject ZRET_PAR. The variables follow the strict naming conventions shown in Table 1. Figure 7 shows an example of the parameters displayed in InfoObject ZRET_PAR.
ERP source system |
Variables beginning with "SOURCE_SYSTEM" |
Mandatory |
Retractor type |
A value in ZRET_TYPE |
Mandatory |
Retractor structure |
Variables begining with "STRUCTURE" |
Mandatory |
ERP data load functional module |
Variables begining with "DATA_LOAD_FM" |
Mandatory |
ERP post data load functional module |
Variables begining with "POST_LOAD_FM" |
Optional |
Test run/actual run |
'TEST_RUN' or ACTUAL_RUN.' |
Mandatory |
|
Table 1 |
Naming standard of the parameters to be used in the retractor planning function |

Figure 7
Retractor parameters in InfoObject ZRET_PAR
Create the Planning Function
Now all the elements are in place and you can create the planning function in SAP NetWeaver BI Integrated Planning. A planning function is created on an aggregation level; this contains the InfoProvider from which you will be extracting. By using the BI Modeler you can create a planning function, filter, and planning sequence. The parameters that you have previously created are selected in the planning function (Figure 8). To select the data from the InfoProvider, you have to create a filter (Figure 9).

Figure 8
Retractor planning function

Figure 9
Selection criteria in planning function filter
Then, all of these are collected in a planning sequence (Figure 10). When the planning sequence is run, data is:
- Read from the aggregation level
- Mapped to the retractor structure
- Sent to the data load function module in SAP ERP
- Loaded into SAP ERP by running the data load function module

Figure 10
Retractor planning sequence
The final retraction results are then displayed in the messages from the planning function (Figure 11). The messages of the planning function show 602 records read, 0 generated, 0 changed, 0 deleted. However, only 284 records are received in the Start of Remote Function Module. This is to be expected as data read from the InfoCube is further aggregated due to mapping criteria. No records are actually altered in the InfoCube. They are only extracted and collected. Then, they are sent to SAP ERP, resulting in 602 records read and only 284 records received.

Figure 11
Retractor messages
Andrew Simmonite
Andrew Simmonite is a senior technical strategy consultant for SAP NetWeaver BW with Capgemini. He has more than nine years of experience with SAP NetWeaver BW and more than 19 years in IT. He has experience in both reporting and planning implementations for multi-national companies in the gas and oil, public-, and retail sectors. He holds a bachelor degree with honors in computer science.
You may contact the author at Andrew.Simmonite@capgemini.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.