ABAP routines help you meet requirements during SAP NetWeaver BW implementations that the standard functionalities of SAP NetWeaver BW cannot meet. In global implementations, these ABAP routines can be used in each country rollout, especially for the country-specific objects.

In multiple country rollouts, it is typical to design and copy a global data model for each country rollout. It can become challenging to keep the subsequent changes to the global data model in sync across all the rolled-out countries. For example, a section of ABAP code used in the start and end routines of the transformation is common across many transformations. Any changes made to that routine for a specific transformation must also be changed for all the transformations.

My team and I have identified an approach in which you can design and implement ABAP routines that keep the data model in sync during implementation across countries, ensuring the production support path and development path are independent of each other during implementation. This more practical method can be used to design start and end routines in transformations, customer exit variable routines for BEx, routines for DTP filters, and customer exits for SAP ERP Central Component (SAP ECC) DataSources.

With this process, function modules are applied to reduce the overall maintenance efforts in large-scale, global SAP NetWeaver BW 7.0 implementations. You can also make post-implementation changes in the function module and the changes are automatically reflected in all the transformations using that function module.

ABAP Routines in Start and End Routines

In SAP NetWeaver BW 7.0, you can use ABAP routines in the start and end routines of the transformations to meet your needs when standard field mapping rules cannot. With this approach, you can effectively manage the ABAP routines in the start and end routine of the transformation to reduce overall maintenance.

In this example, the 0SEM_BCS_10 extractor feeds data to a DataStore object (DSO). In the start routine of the transformation, use the general ledger (G/L) account number to derive the group account number.

Step 1. Create a dynamic internal table using function module YT_CREATE_INTTAB_FM1 and transaction SE37 (Figure 1). For the start routine, create the dynamic table based on the source of the transformation, whereas for the end routine, the dynamic table must be created based on the target of the transformation. For example, if a DSO is updated from an SAP ECC DataSource, the start routine’s dynamic table structure should be based on the field structure of the DataSource. The end routine’s dynamic table structure should be based on the field structure of the DSO.

Figure 1

Function module YT_CREATE_INTTAB_FM1 to create the dynamic internal table (import parameters)

These are the descriptions of the import parameter names in the dynamic internal table:

• I_DS_NAME: This parameter describes the name of the DataSource. For start routines, fill this parameter with the DataSource technical name. For end routines, fill it in with the data target technical name. For example, in a transformation created between an SAP ECC DataSource and a DSO, this parameter should be populated with the technical name of the DataSource when used in start routines and with the technical name of the DSO when used in end routines. DataSources, InfoObjects, and InfoCubes are potential sources and targets for transformations (DataSources are always treated as sources for a transformation).
• I_LOGSYS: This parameter should only be passed when DataSources are used as the source for the transformation. Otherwise, it can be left blank. Use the technical name of the source system.
• I_DS_TYPE: This input parameter identifies the DataSource type. These are the objects you can use as a source and target for a transformation:
  • DataSource – D
  • InfoObject – I
  • DSO – O
  • InfoCube – C

Figure 2 shows how function module YT_CREATE_INTTAB_FM1 can be used to create the dynamic internal table for export parameters. In SAP NetWeaver BW 7.0, the system generates ABAP types in the start and end routines of the transformations. Because the ABAP types are local to the transformation, they cannot be referenced from the function modules. However, communication structures can be referenced directly from the function modules. Therefore, a dynamic table type must be created based on the field structure of the source/target objects for transformations. Table E_DYN_TAB is the dynamic internal table structure of the object used in the import parameter.

Figure 2

Function module to create the dynamic internal table (export parameters)

To use the function modules in the start and end routines of the transformation, refer to the table types of the data package. However, in SAP NetWeaver BW 7.0, the table types are unknown until runtime. Dynamic internal table types are created so they can be referenced within the function module to update the data packages.      

Step 2. Create function module YT_ENDROUT_FM2 to update the data packages in start and end routines (Figure 3). Use this function module to process the data packages in the start and end routines of the transformation.

Figure 3

Function module YT_ENDROUT_FM2 in start and end routines of transformations (import parameters)

The descriptions of the import parameter names in the start and end routines function module are:

• I_REQUEST – Captures the request ID of the data load request
• I_DATAPACKID – Captures the data packet ID of the data load request
• I_DYN_TAB – Captures the dynamic table created in step 1

Figure 4 shows the export parameter for function module YT_ENDROUT_FM2 for start and end routines of transformations. Export parameter I_MONITOR appends to monitor entries. If an exception is raised and the update process is cancelled, the monitor entries need to be appended to help investigate the problem.

Figure 4

Function module YT_ENDROUT_FM2 in the start and end routines of transformations (export parameters)

Figure 5 is function module YT_ENDROUT_FM2 with the changing parameters used in the start and end routines of transformations. Changing parameter L_SUBRC can be used to decide whether to cancel the update process or not. The changing parameter is set to a non-zero value if an exception is raised inside the function module.

Figure 5

Function module YT_ENDROUT_FM2 in the start and end routines of transformations (changing parameters)

Figure 6 shows function model YT_ENDROUT_FM2, which can be created with tables parameters in the start and end routines. I_DATA_PACKAGE is for the tables parameter for data packages. In SAP NetWeaver BW 7.0, pass SOURCE_PACKAGE for start routines and RESULT_PACKAGE for end routines.

Figure 6

Function module YT_ENDROUT_FM2 in the start and end routines of transformations (tables parameter)

To create an exception parameter, use function module YT_ENDROUT_FM2 in the transformation start and end routines (Figure 7). SAP provides CX_RSROUT_ABORT as a standard exception to use when it is necessary to cancel the data packet update in a data target in the SAP NetWeaver BW 7.0 transformation.

Figure 7

Function module YT_ENDROUT_FM2 in the start and end routines of transformations (exception parameters)

Step 3. Call the function modules in the start and end routines created in steps 1 and 2 (Figure 8). Go to the transformation and click on the start and end routine. Call the function module created in step 1 first by clicking the Pattern button and entering the function module you created in step 1. Click the Pattern button again and enter the function module you created in step 2.

Figure 8

Calling function modules in transformation start and end routines

ABAP Routines in DTPs

The following example illustrates how you can reuse the ABAP routines used for restricting the data sets in the DTPs filter.

Say the 0SEM_BCS_10 extractor is feeding data to a DSO. The DSO only stores data for the current open period, which is maintained as a variable in TVARVC. The restriction is applied to the DTP by using an ABAP routine. This ABAP code can be copied across multiple DTPs for multiple country rollouts.

In this example, the application support team decided post-implementation to use a different custom table for these custom variables instead of using TVARVC. This small change requires a significant effort to change the code in all the DTPs. Below is a description of a three-step approach that can help reduce the maintenance effort of such changes in global implementation scenarios.

Step 1. Create a global function module to use in DTPs. Figure 9 shows the import parameters of function module YT_DTP_FILETR_FM3 used in DTPs filter. Use the import parameters as shown below while creating your function module.

Figure 9

Function module YT_DTP_FILETR_FM3 in DTPs filter (import parameters)

The following are the descriptions of the import parameters for the function module in Figure 9:

• I_VAR_NAME – Name of the TVARVC variable.
• I_IOBJ_NAME – Name of the InfoObject for which the ABAP routine is written in DTP
• I_FIELDNAME – Field name in the source. For example, FISCPER (fiscal year period) from the DataSource is mapped to InfoObject 0FISCPER in the DSO. In this case, the field name in the routine is FISCPER and the InfoObject name is 0FISCPER.

Figure 10 shows the changing parameters of function module YT_DTP_FILETR_FM3 used in DTPs filter. Use these changing parameters while creating the function module. Changing parameter I_SUBRC is the return code for errors.

Figure 10

Function module in DTPs filter (changing parameters)

Figure 11 shows the tables parameters of function module YT_DTP_FILETR_FM3 used in DTPs filter. Use these table parameters while creating the function module. Table parameter I_T_RANGE captures the filter criteria.

Figure 11

Function module YT_DTP_FILETR_FM3 in DTPs filter (tables parameters)

Step 2. Create a TVARVC variable. Go to transaction SE11 and enter the table name TVARVC. Click the Display button and follow menu path Utilities > Table Contents > Create Entries. Enter the values shown in Figure 12 and click the save icon to create the table entry.

Figure 12

Creating TVARVC table entries

Step 3. Call the function module from the DTP filter. Go to the DTP filter and select the field for which you want to create the ABAP routine. In the example, the field is fiscal year/period. Figure 13 shows how the function module is called in the DTPs filter.

Figure 13

Calling function modules in DTP filter

Customer Exit Variables for BEx Queries

In this example, variable A represents a customer exit variable to determine the last day of the period the user entered in the query selection screen. Variable B could be any customer exit variable. The purpose of the document is to describe an approach for the customer exit variable in general, which can then be extended to any customer exit variable depending on your specific customer needs.

Figures 14 and 15 show function module Z_BW_WXR_VP001 for the customer exit query variables with import and export parameters, respectively.

Figure 14

Function module Z_BW_WXR_VP001 for customer exit variables for a BEx query (import parameters)

Figure 15

Function module Z_BW_WXR_VP001 for customer exit variables for BEx query (export parameters)

The export parameter for the customer exit variable function module E_T_RANGE is the internal table that captures the customer exit variable values. Here are the import parameters for the customer exit variable function module:

• I_VNAM – Name of the BEx customer exit variable
• I_T_VAR_RANGE – Internal table containing user-entered selection screen values
• I_STEP – Parameter that captures the various activity of query execution

Call the function module shown in Figure 14. This function module has a specific naming convention. The technical name contains the name of the actual BEx query variable name (in this example, WXR_VP001) prefixed with a constant Z_BW_. You can choose the prefix, but it is critical to have the technical name of the BEx query variable in the function module. This means a corresponding function module should be created for every BEx customer exit variable.

Call this function module dynamically in the standard SAP enhancement RSR00001, which is used for enhancements for global variables in reporting. Sample code is available for download via this link.

Customer Exit for DataSources

To transfer G/L account master data from SAP ECC to SAP NetWeaver BW, the master data is extracted from the database table SKB1, which stores the company code segment view of the G/L account. The DataSource should be enhanced to populate the chart of accounts from table SKA1. SAP provides standard customer exit EXIT_SAPLRRS0_001 included in the standard SAP enhancement RSR00001 for the master and transaction data extraction. The exit can be accessed in two different ways:

1. Go to transaction SE37. Enter the name of the standard SAP exit EXIT_SAPLRRS0_001 and click the Display button.
2. Go to transaction SMOD. Enter the name of the standard SAP enhancement RSR00001. Click the Components button to access the standard SAP exit EXIT_SAPLRRS0_001.

SAP has also provided standard enhancements for enhancing the DataSources. These enhancements can be accessed using transaction CMOD. In case of the above scenario, in which the data source must be enhanced to populate the chart of accounts, write an ABAP routine in the SAP-delivered standard enhancement.

Note
An assumption is being made that the DataSource in the system has already been created and activated the SAP-provided exit. Therefore, details on DataSource creation are not discussed in this article.

Follow these steps to help reduce the maintenance effort for customer exits used to enhance the DataSources in global implementations and rollouts:

Step 1. Create function module YT_DATASOURCE_EXIT for customer exits for DataSources using transaction code SE37 (Figure 16).

Figure 16

Function module YT_DATASOURCE_EXIT for customer exit for DataSources (import parameters)

These are the import parameters for the customer exit for DataSources function module:

• I_DATASOURCE – Name of the DataSource for which the customer exit is used
• I_CHABASNM – Name of the InfoObject (this is optional)
• I_UPDMODE – Data transfer mode (Full, Delta). This identifies whether the data requested is a full or a delta request. You can use this field to differentiate the ABAP coding. Otherwise, this field is optional and should not be used anywhere in the source code of the function module.

Figure 17 is function module YT_DATASOURCE_EXIT with table parameters you create in DataSource customer exits.

Figure 17

Function module YT_DATASOURCE_EXIT

Table parameters for customer exit for DataSources function module are:

• I_T_SELECT — This table contains the selection conditions in the InfoPackage used to extract data from SAP ECC
• I_T_FIELDS — This table contains the list of all the fields available for extraction. If any fields are marked as hidden in the extract structure, the field is unavailable in this table.
• I_T_DATA — This table contains all the data records extracted according to the InfoPackage selection and requested update mode prior to the customer exit call. In the customer exit, the table entries need to be updated as per the business requirement.
• C _T_MESSAGES — If you encounter any errors during the customer exit, you can update this internal table with system messages, which raises exceptions on the SAP ECC side and cancels the data load process.

Figure 18 shows the customer exit for DataSources function module Z_BW_0GL_ACCOUNT_ATTR for exception RSAP_CUSTOMER_EXIT_ERROR. This exception is raised when there are errors in the customer exit.

Figure 18

Function module Z_BW_0GL_ACCOUNT_ATTR for customer exit for DataSources (exceptions)

Step 2. Call the function module created in step 1. This function module has a specific naming convention. The technical name contains the actual DataSource name (e.g., 0GL_ACCOUNT_ATTR) prefixed with a constant Z_BW_. You can choose the prefix, but it is critical to have the technical name of the DataSource in the function module. For every DataSource in SAP ECC that needs to be enhanced by a customer exit, you must create a corresponding function module. Also, since the SAP standard enhancement is called in SAP ECC prior to the transfer of data from SAP ECC to SAP NetWeaver BW, you must create the corresponding function modules in SAP ECC.

Call the function module in Figure 16 dynamically in the standard SAP enhancement RSAP0001, which is used for customer function calls for DataSources in service API.

Soumya Mishra

Soumya Mishra is a senior BI practitioner with a total of eight years of experience in the SAP BI space. He has been continuously focused on developing business enabling analytic strategies and solutions. He has extensive enterprise analytics assessment knowledge and has successfully played a key role in delivering large-scale finance transformation solutions that deliver actionable information and insight to users, giving them the ability to make informed decisions. He has deep knowledge of BI, and SAP ECC FI/CO configuration, as well as experience with implementations in several Fortune 500 companies in the consumer products and financial services industries. He is a certified SAP BI solution consultant with deep experience in development and integration of BI strategy; process redesign with information systems; and project planning and implementations with strong communication, organizational, and project management skills. You can view his LinkedIn profile at https://www.linkedin.com/profile/view?id=50199012&locale=en_US&trk=tab_pro.

You may contact the author at srmishra@us.ibm.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.