Most SAP NetWeaver BI customers use routines to transform data such as unit of measure (UOM) conversions and lookups against master data tables in update and transfer rules. In the BI capabilities of SAP NetWeaver 2004s, SAP has introduced transformations, a new method for applying business and technical logic to data. Transformations replace transfer and update rules. Once you decide to migrate, you need to understand how to perform this migration. I will provide guidance and examples to enable the migration to the new transformation process.

You may choose to execute a technical upgrade and preserve the objects built with BW 3.x. Transaction RSA1OLD allows you to continue working with 3.x objects. Thus, you have the option to migrate to newer objects when your project timeline and budget permit. In other words, upgrading to SAP NetWeaver 2004s does not mandate you to use the concepts introduced in the new release and your investment in this area of SAP BW thus far does not go to waste. However, migrating your objects to the new transformation process has some distinct advantages.

Benefits of Migration

Since SAP has chosen this new methodology as the preferred technology going forward, any new enhancements in the data staging area will apply to this method. Consequently, SAP will stop improving the older method. It not only makes sense to perform any new developments using the new methodology, but also to migrate older objects so you better align your implementation with SAP’s vision.

Transformations have an intuitive and graphical representation of column mapping that shows how the source fields are assigned to the target fields (Figure 1). A separate screen displays the details of row-level transformations (Figure 2).

Figure 1

Graphical representation of column mapping

Figure 2

Field level routine for 0ACCNT_GRP

New features called end and expert routines offer flexibility in implementing transformation logic. An end routine is similar to a start routine except that it executes after the row-level transformation logic completes for a given packet. For example, if you want to delete records for a given range of profit centers where the profit center is determined in the row-level transformation logic, you can use an end routine.

An expert routine does not contain start/end routines or row-level routines, and the developer can write the complete logic from scratch. Expert routines are particularly helpful in transposing a wide data record into several smaller records. However, keep in mind that the programmer has to manually code the message transfer to the monitor. Otherwise, you cannot monitor the load.

Expert routines allow programmers to incorporate all transformation logic in a single location. This makes it easy to comprehend and debug the transformation logic. By contrast, to have a complete understanding of how BW 3.x modifies a field, you have to review the start routine and row-level routines in both transfer and update rules.

Transformations in SAP NetWeaver 2004s offer a sophisticated UOM conversion similar to currency conversion. In BW 3.x, you need to do significant ABAP programming for UOM conversion.

ABAP vs. ABAP Objects

One major difference between transfer/update rules in BW 3.x and transformations in SAP NetWeaver 2004s is that you have to write routines in transformations using ABAP Objects. ABAP Objects is an object-oriented (OO) extension to ABAP. In contrast to a procedural language in which the programmer breaks down the logic into reusable subroutines, in an OO language the programmer organizes the logic into code capsules that include both data elements and operations on those data elements. Such a capsule is called a class. Generally, a class represents a real-world object, like a customer or a material.

In ABAP Objects, an operation using the data elements in a class is called a method. The main goal of an OO language is enhancing code reusability and better organizing the code. SAP took the initial steps toward OO programming in R/3 Release 4.0. During that step, SAP also attempted to cleanse the ABAP syntax by eliminating and mandating certain syntax constructs, which I’ll explain below.

While an ABAP routine in transfer/update rules is a form, in transformations it is a method. In transformations, developers do not have to develop any new classes because SAP delivers the necessary classes and methods; the developers just have to implement the methods in those classes. However, when migrating the old code from transfer/update rules to transformations, ABAP Objects requires certain code changes. SAP imposes the changes as a part of cleansing the ABAP syntax. Some commonly used syntax constructs that have to change are:

• Internal table declarations with OCCURS are not allowed. For example, the code in Figure 3 is incorrect, while you could use the code in Figure 4.

Figure 3

Example of code that does not work with ABAP Objects

Figure 4

Example of code that works with ABAP Objects

• Internal tables with header lines are not allowed. Header line in an internal table is a default line that the system uses when looping through the internal table.


• Short forms of internal table line operations are not allowed. For example, you cannot use the syntax INSERT TABLE itab. However, you can use INSERT wa INTO TABLE itab.


• Transformations do not permit READ itab statement in which the system reads values from header lines. For example, the code READ TABLE itab. is now outdated, but you could use the code READ TABLE itab WITH KEY . . . INTO wa.


• Calling external subroutines using the syntax PERFORM FORM(PROG) is not allowed. In this example, FORM is a subroutine in the program PROG.

Migrate Transformation Logic

Next, I’ll summarize the steps involved in migrating the transformation logic from transfer/update rules to transformations.

Step 1. Copy transfer rules. Copy start routine, if it exists. Copy individual rules.

Step 2. Copy update rules. Copy start routine, if it exists. Copy individual rules.

Step 3. Update start routine with return table logic. This is because SAP NetWeaver 2004s does not support return tables yet.

Step 4. Leverage built-in UOM conversion. Create conversion types for UOM conversions or identify existing conversion types. Eliminate any custom code that performs UOM conversion.

Step 5. Create transformation groups. Transformation groups replace the previous concept of key figure-specific update rules for characteristics. In update rules for InfoCubes, if you have applied transformation logic to characteristics with respect to any key figures, then create appropriate transformation groups. In update rules for ODS objects, if you have applied transformation logic to key fields with respect to any non-key fields, then create appropriate transformation groups.

Example of Migrated Code

Next, I’ll show you how to migrate ABAP code to ABAP Objects code. Suppose a DataSource sends five fields (Calday, DocNo, Line, Customer, and Material) and the InfoProvider contains two additional fields — Account Group (an attribute of Customer) and Material Group (an attribute of Material). Suppose the InfoSource contains all seven fields.

Figures 5 through 10 highlight the differences in code between BW 3.x and SAP NetWeaver 2004s. In this code, Account Group has been filled in the transfer rules. A start routine fills an internal table, whereas the individual transfer rule fills Account Group by reading the internal table. Figure 5 shows the code before transformation and Figure 6 shows what the code looks like in SAP NetWeaver 2004s. Figure 7 displays the individual ABAP routine for Account Group and Figure 8 shows the migrated code for SAP NetWeaver 2004s.

Figure 5

Start routine for Account Group in BW 3.x transfer rules

Figure 6

InfoSource’s transformations for Account Group in SAP NetWeaver 2004s

Figure 7

Individual ABAP routine for Account Group in BW 3.x

Figure 8

InfoSource’s transformations for Account Group in SAP NetWeaver 2004s

Likewise, Material Group has been filled in the update rules. A start routine fills the lookup internal table and also the data packet internal table so the individual update rule can be a one-to-one field mapping. Figure 9 shows the code before transformation and Figure 10 shows the code in SAP NetWeaver 2004s.

Figure 9

Start routine for Material Group in BW 3.x

Figure 10

InfoSource’s transformations for Material Group in SAP NetWeaver 2004s

Sankar Tadinada

Sankar Tadinada is a technical architect at Erada Systems with over 14 years of IT experience and more than 10 years of SAP experience. He has been providing consultancy in the SAP BI space since 2000. His expertise spans BW data modeling, ETL and reporting, R/3 and BW performance tuning, and ABAP and Java development. He also instructs at the SAP Partner Academy and has taught several BW classes including advanced courses like BW360, WNABW7, and NW2004s Delta at SAP and its clients.

You may contact the author at sankar@erada.com.

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