SAP NetWeaver BW reduces the need for ABAP for most reporting tasks, but most SAP NetWeaver BW projects could benefit from having an experienced ABAPer available. This is particularly true for data preparation and preprocessing functions. The author shows how an ABAP programmer would be useful in 20 different areas.
If you ask a CIO why his or her company implemented SAP NetWeaver BW, the answer might include a desire to do away with custom ABAP reports. It's true that SAP NetWeaver BW can eliminate the need to create ABAP reports. In addition, the transformation library, which writes ABAP code for you, further reduces dependency on ABAP, as do alternatives such as XML/SOAP, Java, and external extraction, transformation, and loading (ETL) tools. However, does SAP NetWeaver BW totally eliminate the need for ABAP coding?
No. So, don't send the ABAP programmers home so quickly!
ABAP programmers who are familiar with SAP NetWeaver BW will be assets to most projects. However, their focus, with a few exceptions, will move from report creation to data preparation and preprocessing functions. Figure 1 shows areas within the standard SAP NetWeaver BW architecture where you might use ABAP:
- Six places during extraction, including creating custom DataSources, enhancing DataSources, and data selection in InfoPackages
- Six places during staging, including currency/units of measure conversions, transfer routines, and update rules
- Four places during reporting, including generating system-entered variables and the report/report interface
You also have four other opportunities in SAP NetWeaver BW to use ABAP: Open Hub Service transformations, building authorization values, process chains, and virtual InfoCubes with services.

Figure 1
20 ways to enhance SAP NetWeaver BW with ABAP
That's a total of 20 ways you can use ABAP to enhance the operation and utility of your BW system. This article introduces you to each of them.
Six Ways to Enhance Data Extraction with ABAP
1. Create a custom DataSource for an InfoSet query with the generic extractor. When no standard application-specific extractor is available for a given DataSource, you might have to create your own using the generic extractor (transaction RSO2). Like all extractors, the generic extractor uses a function module called by the service API when SAP NetWeaver BW requests the data to be loaded. This function module is written in ABAP code.
Although you can use transaction RSO2 to build DataSources based simply on tables or views where no custom ABAP code is needed, more sophisticated uses of the generic extractor might involve custom ABAP code. One example might be when you use InfoSet query to feed the generic DataSource. This query-writing tool has been included in the Basis layer of all SAP products (under one name or another) for many years. It collects data in memory and is used as a source for user ad hoc queries (mostly in SAP ERP). Instead of using the InfoSet query to report against data in SAP ERP, the SAP NetWeaver BW team uses the data collected by the InfoSet as a feed for a generic DataSource. You have many options for filling the InfoSet. One option is by means of ABAP code, in which your code indirectly serves as the extractor program.
If you have SAP BW 3.x, you would use this option only if you have existing InfoSet data from SAP R/3 that already uses ABAP as the source.
2. Create a custom DataSource directly using transaction RSO2. As of Release 3.0B, you can use the generic extractor tool to create custom DataSources, complete with your own ABAP-coded function module, but in a more direct way than when using the InfoSet query. With 3.0B, RSO2 has an option to base a DataSource directly on a custom-written ABAP function module, as shown in Figure 2. All you need is an extract structure and an ABAP program to fill it and you have yourself a DataSource. If extraction is more complicated than just a view or a table, this is the preferred way to use your own ABAP code as the extractor function module in SAP NetWeaver BW.

Figure 2
Create a custom DataSource directly from RS02
3. Enhance a DataSource and associated extractor function module. SAP-delivered DataSources don't necessarily contain all the information that your requirement demands. In many cases, you must add fields to the DataSource's extract structure and then fill them via a customer exit. SAP provides customer exits for transactional data (EXIT_SAPLRSAP_001), master data (EXIT_SAPLRSAP_002), text (EXIT_SAPLRSAP_0003), and hierarchies (EXIT_SAPLRSAP_0014). It's up to you, however, to write the simple ABAP code needed to look up the fields added to the delivered extract structure.
4. Select files from flat-file DataSources. When loading flat files, the SAP NetWeaver BW InfoPackage must know the file name and the location of the file. Sometimes a file that is on the server — for example, Current_Mth_Sales — is reloaded with the data you loaded last month by mistake. This mistake is difficult to catch, and SAP NetWeaver BW does not know the file contains old data. People are fired over problems like this!
An ABAP program can help here. On the External Data screen (Figure 3) in the InfoPackage, you can place a routine to dynamically determine the file name to load. Combined with naming conventions agreed to by the legacy team, this routine makes it easy to catch this type of mistake. The ABAP routine determines the file name based on the SAP-delivered variable for “current system month,” so that a file to load in December is SALES_12, and the following month (January) it would be SALES_01. If the IT group does not get a file on the server with this exact name, the load fails, forcing an investigation and avoiding a serious mistake.

Figure 3
Place an ABAP routine to identify the file name to be loaded
5. Determine data selection in an InfoPackage. In some cases, not all the data from a DataSource is needed in SAP NetWeaver BW. For example, it might be old and unchanged from the previous load. Also, the SAP NetWeaver BW implementation might not be designed to support the whole corporation, and it is necessary to extract only limited organization-specific data to SAP NetWeaver BW.
You can select specific data by clicking the Selection tab of the InfoPackage. This selection can be dynamic (change with each InfoPackage load) or fixed (only company code 1000 for year 1999). If you want it to be dynamic — for example, to extract only the current fiscal period — then two options exist: variables or an ABAP routine to fill in the value of the selected data at extraction time. You could use SAP-supplied variables for determining the current month, but when determining other characteristic values with more complex logic, you would need your custom ABAP code.
6. Determine automatic deletion of similar loads. It might be necessary to load FEB_2000_FI_DATA on February 15, 2010, and again on February 28, 2010. If this is done without forethought, you risk double-counting data from February 1 to 15. You must make sure you delete the load on the 15th from the data target for the load on the 28th to avoid double-counting. SAP NetWeaver BW contains simple logic that can be activated to determine if a prior load with similar selections should be deleted. The settings for the checking logic are located under the Data Targets tab. The simple checks, such as Are the InfoPackage selections the same? and Was the original info package loaded in the same week? can be set with delivered check boxes. For more complex logic to determine overlap or duplicate loads, you can use ABAP code. If a duplicate is detected, then the system automatically deletes these prior load requests to avoid double-counting the records
Six Ways to Enhance Data Staging with ABAP
Data staging is the manipulating and cleansing of data after it arrives in SAP NetWeaver BW. Data staging includes the transfer and update rules. You could substitute “ABAP” here for the word “rules,” as in transfer ABAP and update ABAP. These data manipulations are for the most part written for you by SAP NetWeaver BW. Complex look-ups or derivations are not written for you. In these cases, who are you going to call? You guessed it: an ABAP programmer! The ABAP code needed in data manipulation is normally simple.
1. Write complex logic for transfer procedures. The transfer procedures clean the incoming transfer structure fields and write the clean data to the communication structure (known less technically as the InfoSource). These procedures can be accessed from either the DataSource or the InfoSource overview trees, as the transfer rules are the “glue” connecting the dirty DataSource to the clean InfoSource. The procedures can be as simple as a field-for-field move or can involve complex logic. However, what if field lengths or types are different? What if you needed a complex look-up in two or three tables to derive the proper value? For this and more complex logic, you need to write ABAP code or use the transformation library to create the code for you (Figure 4).

Figure 4
Transfer procedures (all types)
2. Transfer routines. Transfer routines are similar to transfer procedures, as both are part of the transfer rules that perform cleansing functions in the data flow. The main difference is how they are created and when they are applied. Transfer procedures are maintained on the Transfer Rules section of the InfoSource, while transfer routines are maintained on the InfoObject's General tab. If a transformation should take place for every occurrence of an InfoObject, regardless of what InfoSource is being loaded, the transformation logic (written using ABAP) can be maintained directly on the InfoObject. This means less work, since rules need be maintained only once and take effect during all cleansing transformations associated with the InfoObject. If transfer procedures and routines are both applied, the logic (ABAP) on the InfoObject (transfer routines) is executed before the logic (ABAP) on the transfer rules.
3. Update rules in general. Update rules allow the manipulation of the clean data for the purposes of summarizing or customizing data for a specific reporting purpose. The targets of the manipulated InfoSource data include DataStore objects (DSOs), InfoCubes, and master data (text and attributes). Update rules provide automatic determination of date-based mapping (e.g., 01/01/2010 = WEEK 01/2010) and can even automatically generate the code for simple look-ups of master data attributes. However, if your manipulation requirements fall outside of these more basic tasks, you can use the transformation library or directly write ABAP for complex logic.
4. Return a table versus a record. In standard updating logic, one record in the InfoSource is loaded as one record in the InfoCube. In some cases, it is necessary to create a table (more than one record) to be loaded to the InfoCube for each incoming record in the InfoSource. Business examples of this might be legacy sales order data missing the detail for a specific sales rep. The business rule might be to assign one-fifth of the sale to each of five sales reps. The business rule (written in ABAP) would then split the single sales order into five smaller records, each with one-fifth of the amount.
5. Convert currency or units of measure. In most cases, currency conversion logic is better handled through the use of translation keys in the bottom section of the Update Rules screen. However, conversions from inches to meters or liters to gallons are not as conveniently performed. In many cases, this logic requires ABAP code. By selecting the Unit Calculation in the Routine check box on the Update Rule: Detail screen (Figure 5), you can code a “unit routine” with ABAP to handle complex manipulations of currency. For example: “Look at the date and the from/to currency, and then convert based on a 70/30 weighted average for the high and low rates.” Similarly, you can convert gallons to liters.

Figure 5
Update rules
6. Create custom start routines for transfer and update rules. Transfer or update programs are generated automatically when you activate a transfer or update rule. Simple code for tasks such as “move corresponding fields” or “assign fixed values to InfoObjects” combines with your custom code. In this combined program, individual records flow from memory-resident structures to the data targets (InfoCubes, DSOs, and InfoObjects). Because the code is executed one record at a time, it can be inefficient to process some tasks, especially ones that require a table look-up on the database.
You can alleviate this potential bottleneck by creating a start routine, which is custom ABAP code that executes at the start of the transfer or update rule program (Figure 6). This custom code can, for example, fill global variables or, more importantly, build a memory-resident version of the look-up tables required by the rest of the program. If a rule is processing many records, and the building of the involved look-up tables is not a long process, then you can realize dramatic improvements in performance.

Figure 6
Start routine
Four Ways to Enhance SAP NetWeaver BW Reporting with ABAP
1. Generate system-entered variables. Many reports can use system-entered variables, in which the user is not prompted for the value. The system determines the value in the background. These variables are either delivered by SAP (current month, for example) or created on a custom basis. For the latter, a user exit is available for ABAP code. The ABAP code is run at query execution time and is used to determine the variable values for this one query run by a specific user at a specific time.
Your ABAP code, entered under the user exit shown in Figure 7, can perform look-ups or other complex logic. The logic determines the values without asking the user to input them.

2. Populate virtual key figures and characteristics. What happens if the data needed by a query is not derivable using formula functionality or must be looked up at execution? This might be because the data or a reference needed by a calculation is unavailable in the SAP NetWeaver BW target. The system provides a user exit to process the data retrieved from the database on the way to the user. An InfoCube that needs these runtime-created characteristics or key figures must contain a special virtual key figure or characteristic that has no data in it, but is added to reports in the normal manner. The user exit's job is to populate these otherwise blank InfoObjects when the report is executed using custom ABAP code.
3. Modify Web-based table and navigation block interfaces. You probably know how SAP NetWeaver BW works in a Web environment: A Web template provides placeholders for tables and charts that are populated with data at the time the page is requested. The template is a simple page to create, while the page that is actually sent back by SAP NetWeaver BW contains JavaScript and HTML surrounding the real table, which by necessity is complex. It is good that you do not have to create this output yourself. It is the responsibility of the SAP NetWeaver Application Server (SAP NetWeaver AS) or the Internet Graphics Server (IGS).
However, if someone designed the template one way, someone else will want the output to look or behave differently. Who are you going to call? If you said an ABAPer, you would be wrong! This time, you need an ABAP object-oriented (OO) programmer. ABAP OO uses object-oriented techniques similar to those of other languages such as Java and Visual BASIC. Working with the ABAP OO programmer, you can change the output generated for the table or the navigation block (the central place where you click on the report to drill down on a specific characteristic). You can add your own icon, for example, to run a customer-specific process with the data in a cell, or just have a mouse button do something different for your Web page. If you don't have an ABAP OO programmer handy, a regular ABAPer provided with a white paper showing an example of what you want to do should serve just fine.
4. Report-report interface (RRI). The RRI allows users to navigate from one SAP NetWeaver BW query (on InfoCube X, for example) to another query on InfoCube Y. It also allows you to jump to SAP ERP or SAP Customer Relationship Management (SAP CRM). Although you would probably not need new ABAP code, you can use RRI to run any ABAP report on any SAP system (e.g., SAP ERP, SAP CRM, SAP NetWeaver BW, or SAP Advanced Planning & Optimization [SAP APO]).
Four Additional Ways to Enhance SAP NetWeaver BW with ABAP
1. Perform Open Hub transformations. SAP NetWeaver BW supplies the Open Hub service to meet requirements for getting information to third-party applications from SAP NetWeaver BW. The data types, field names, and field lengths are often not the same in SAP NetWeaver BW as they are in the external application, or additional value manipulation is necessary. For this, an ABAPer needs to code the custom logic for the manipulation in a Business Add-In (BAdI). BAdIs, based on ABAP OO, help you accomplish custom enhancements in a controlled way.
2. Build authorization values. ABAP implemented through variables filled by a user exit can be used to dynamically build authorization values when the user logs in. This is sometimes an easy way to maintain many allowed values for a cost center range for a specific user.
3. Process chains. The process chain is a scheduling tool for various tasks in the data warehouse. In some cases, you can use ABAP code to schedule a job on the source system or run a small ABAP program on SAP ERP to raise an event on SAP NetWeaver BW. This event could then be used to start a process chain. A business case for this could involve a transaction or ABAP code run on SAP ERP to indicate that the Financial Accounting (FI) system is done with the month-close process. This ABAP program calls SAP NetWeaver BW and raises an event. When this event is raised, the process chain called “FI Monthly Process” starts.
4. Virtual InfoCube with services. Virtual InfoCubes allow for the direct read of source data in real time. You do not have to load the data into an InfoCube — it is loaded into memory directly from the source when the report is run using standard SAP NetWeaver BW query and reporting tools. The three types of virtual InfoCubes are SAP remote InfoCubes, general remote InfoCubes, and virtual InfoCubes with services. SAP remote InfoCubes use SAP ERP or SAP CRM DataSources (and their associated extractors) to read the data in real time, while general remote InfoCubes access data that is normally purchased (e.g., Nielson). Virtual InfoCubes with services are used if the source is a custom table or group of tables. In this case, custom ABAP function modules (services) can be written to properly present the data from these tables to the SAP NetWeaver BW query tools, making your table look like an SAP NetWeaver BW InfoCube. This provides real-time data, not replicated data, from your application to the user.
Ned Falk
Ned Falk is a senior education consultant at SAP. In prior positions, he implemented many ERP solutions, including SAP R/3. While at SAP, he initially focused on logistics. Now he focuses on SAP HANA, SAP BW (formerly SAP NetWeaver BW), SAP CRM, and the integration of SAP BW and SAP BusinessObjects tools. You can meet him in person when he teaches SAP HANA, SAP BW, or SAP CRM classes from the Atlanta SAP office, or in a virtual training class over the web. If you need an SAP education plan for SAP HANA, SAP BW, BusinessObjects, or SAP CRM, you may contact Ned via email.
You may contact the author at ned.falk@sap.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.