Company ABC has used SAP NetWeaver BI for two years. It has implemented BI InfoProviders for the financial department (such as for cost center and the financial ledger). This company is now running a new project for implementing material management (MM) and plant maintenance (PM) InfoProviders in the logistics area.

The financial team had used the user exit on the SAP ERP Central Component (SAP ECC) source system to enhance some DataSources because the standard ones provided by SAP did not meet all their requirements. While developing the logistics BI project, the team realizes it also needs to use the same user exit to enhance the inventory management DataSource, and it starts to add coding into this user exit.

In the meantime, the finance department discovers something wrong with the BI reports, and an urgent problem has to be fixed in the user exit for the finance DataSource. During the testing of the fix in the quality assurance system, a developer realizes that the coding added by the logistics team references a new table, ZMM_01, which is not in the production system (because this project is not yet live). Because of this, the transport of the fix to the production system will fail.

After several meetings, the logistics team decides to remove the coding that references the ZMM_01 table to let the finance fix go to production. This is the traditional approach that organizations typically use. This operation takes time, so the fix has to wait a week to go to production, delaying the resolution of the problem. The logistics team must then put back its coding and retest it, consuming more precious time on the project.

Disadvantages of the Traditional Approach

The ABAP code in Figure 1 shows what usually happens in companies using a traditional approach. Each CASE reference is for a DataSource. Each developer works on one or many DataSources.

The traditional approach has many disadvantages. First, multiple developers cannot modify the standard user exits at the same time. This means that one has to wait for others before creating the changes. On small projects this is not a challenge because the need to add extra logic on DataSource user exits typically does not happen daily. However, in large projects or environments, this wait time can become a constraint.

Sharing the same user exit also means that one developer could cause unwanted changes elsewhere in the system. For example, if a developer puts code in the user exit that contains technical errors, this affects all DataSources. The extraction of data from that source system would not be possible until the code is fixed. In BI projects, these situations can cause serious problems.

A major issue is the management of many deliveries (e.g., enhancements and fixes) with different implementation dates. For example, project A starts and adds some logic to the user exit. In the meantime, project B must also add logic to the same user exit. Project B needs to go to production before project A, so it sends a transport to production that contains the logic for project A. The user exit may then reference ABAP objects (e.g., tables or structures) that are not present in production. This not only causes transport errors, but it could also generate errors during BI extractions.

Of course, it is possible to manage this problem by looking carefully at the user exit code to make sure that transports are always free of errors. In some cases, you must remove the changes to the user exits, which is an inefficient and time-consuming process. In my example, if delivery A removed its logic in the user exit, it would enable delivery B to go to production without affecting anything. Delivery A would then need to put its logic back.

The Flexible Approach

A much better way of managing the user exits is what I call the flexible approach. By slightly modifying the user exit code, you can easily avoid the problems mentioned in the previous section. The method is simple: after the developers make the initial changes, the user exit calls an independent ABAP program that contains the business logic required for the DataSource. With a proper naming convention, which I will describe later, it is easy to call a different ABAP program for each DataSource.

Having one separate program per DataSource also has another advantage: When you need to look at the extraction logic for a given DataSource, it’s much easier to look at a single program that contains all the code related to that DataSource. This method facilitates the system documentation. Otherwise, having to browse within a shared user exit containing code for many DataSources can be quite confusing.

After you apply the generic code in SAP ECC, you do not need to alter the user exit anymore. You only need to create a distinct program for each DataSource.

Table 1 shows the available user exits, depending on the type of data. In this flexible approach, developers work with their own DataSources. You must activate these user exits before putting the flexible approach in place. This is a common process, so chances are they are already active if you have had your SAP NetWeaver BI system for a while.

Table 1 User exits that are available on the source system

Note
EXIT_SAPLRSAP_003 was implemented in previous versions of SAP BW and is not used anymore.

How to Apply the Flexible Approach

In my example, I use user exit EXIT_SAPLRSAP_002, which is for master data (attributes and texts). However, you can apply this concept to other user exits.

Search for function module EXIT_SAPLRSAP_002 with transaction SE37. You can also access it with transaction CMOD by displaying the components and double-clicking the function module.

Double-click include ZXRSAU02 (Figure 2). Click the Change button to access the edit mode. This is where you implement the generic code that the system calls each time you execute a DataSource.

Figure 2

The include ZXRSAU02 is embedded in the function module EXIT_SAPLRSAP_002

Enter the code shown in Figure 3 in the edit window. Then save and activate the program.

Figure 3

The generic code that you enter into include ZXRSAU02

The logic that the generic code performs is simple: When the code calls the DataSource from SAP NetWeaver BI, it builds a program name with the DataSource technical name preceded by a Z_. For example, for the 0MATERIAL_ATTR DataSource, the code builds the program name Z_0MATERIAL_ATTR. Then, the system searches the program name table (TRDIR) to check if the program exists. If this is the case, the system calls a subroutine within the program Z_0MATERIAL_ATTR. The relevant information (data, selection, field name, update mode) is passed to the program, which can now perform the logic specific to the DataSource.

When you’ve finished entering the general code, all you need to do is add a new ABAP program for each DataSource when enhancements are required. Go to transaction SE38 and create a new program with the name that corresponds to the DataSource (in my example, Z_0MATERIAL_ATTR). Generally the program has the structure shown in Figure 4. This is where the developer inserts the business logic to enhance the DataSource.

REPORT Z_0MATERIAL_ATTR. FORM ZR_0MATERIAL_ATTR TABLES I_T_DATA I_T_SELECT STRUCTURE 
            
RSSELECT I_T_FIELDS STRUCTURE RSFIELDSEL USING I_UPDMODE. DATA: S_MATERIAL_ATTR LIKE 
            
BWE_MATERIAL_ATTR OCCURS 0 WITH HEADER LINE, V_TABIX LIKE SY-TABIX. CLEAR: S_MATERIAL_ATTR, 
            
V_TABIX. LOOP AT I_T_DATA INTO S_MATERIAL_ATTR. V_TABIX = SY-TABIX. ...Customer logic... 
            
MODIFY I_T_DATA FROM S_MATERIAL_ATTR INDEX V_TABIX. ENDLOOP. ENDFORM.
            

Figure 4 Typical ABAP program that the user exit calls

The parameters and tables that you can use are slightly different for transactional, attribute, text, and hierarchy data. Uset these links to download sample code for function module EXIT_SAPLRSAP_001 and function module EXIT_SAPLRSAP_004.

The Flexible Approach on Other Source Systems

In addition to SAP ECC, this approach also works on other source systems, such as SAP Customer Relationship Management (SAP CRM), Advanced Planning and Optimization (APO), or even another SAP NetWeaver BI system. It is also possible to use this method for the user exits that reside in SAP NetWeaver BI. For instance, on the SAP NetWeaver BI system, the user exit EXIT_SAPLRRS0_001 allows you to add custom logic to BEx variables.

Traditionally, all changes made on the variables are placed in the same code, but it is also possible to use the flexible approach. When you use the traditional approach, it could be useful to have an overall view of all variables on the same code. For example, when developers need to add a new BEx variable that requires a specific logic, they would first look at the user exit to see if somebody else already developed it. Then it would be necessary to deal with the disadvantages described above. Each company has to validate if it’s worth using the flexible approach or not, regarding the number of deliveries (how many and whether or not they are at the same time), the size of the project team, and the way it wants to manage operational support.

If your SAP NetWeaver BI environment is already in production, and you are using the traditional approach, you may wonder if it is too late to switch to the flexible approach. The answer is no, because both methods can cohabit. Your company can implement the flexible approach while preserving the code for the user exits if you don’t want to move all existing coding into separate programs immediately. However, in the long run, it would be advantageous to move the code existing in your user exits in individual ABAP programs using a separate program for each DataSource, as described above. In this way your company can have one way to carry out this process, which facilitates the operational support of your system.

Christian Harrington

Christian Harrington is an independent SAP NetWeaver BI consultant. He has worked with BI tools since 2000, helping large companies implement data warehouses. He has 13 years of experience in IT and has worked as a developer, functional analyst, business analyst, and architect. You may contact him in English or French.

You may contact the author at christian.harrington@videotron.ca.

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