Quick Tip: 3 Methods for Identifying and Remediating Custom ABAP Code Issues When Migrating SAP BW to SAP HANA
A crucial step during a migration of SAP Business Warehouse (BW) to SAP HANA database is the analysis of existing ABAP code. As a result of such analysis, potential performance issues can be identified well in advance and remediated by adapting data transformation routines and other custom code to make optimal use of SAP HANA’s in-memory technology.
Besides performance, another major reason for analyzing ABAP code during a migration to SAP HANA is the risk that custom development may simply break, yielding syntax errors after the SAP BW application is upgraded to newer versions (7.4 or higher). This may occur when its syntax relies on Data Dictionary elements whose definitions have been modified by SAP. This is the situation, for example, for Data Dictionary structure RRRANGESID. In this case, its HIGH and LOW field definitions were changed (in the 7.4 of SAP BW release) from being based on CHAR type to SSTRING type. Such a change can easily force remediation activities on custom ABAP code relying on the former CHAR-based definition.
I show three techniques for performing checks and identifying enhancements to custom ABAP code that are required during a migration of SAP BW to SAP HANA database. I also give an overview of some typical errors and warnings that are issued during such checks, as well as ways to remediate them, including code samples. It is assumed that the original SAP BW system being upgraded is already Unicode-compliant, so no changes to Unicode-related code are discussed.
Explore related questions
Identifying the Required ABAP Code Enhancements
There are three methods that you can use to identify the ABAP code enhancements required during an SAP HANA migration project. They are:
- ABAP program ZBW_ABAP_ANALYZER (SAP Note 1847431)
- The Code Inspector tool (accessed via transaction code SCI)
- Program search (in this case, searching for programs that use standard structure RRRANGESID)
The next sections describe each of these methods, as well as the most commonly found issues and how to remediate them. This should not be considered to be a comprehensive list of possible cases but rather as examples of more common issues that tend to occur and need to be addressed.
Method 1: Using ABAP Program ZBW_ABAP_ANALYZER
Program ZBW_ABAP_ANALYZER is provided via SAP Note 1847431. This program searches for issues contained in the ABAP syntax that is used for data manipulation within an SAP BW application. This includes transformations, update rules, transfer rules, and Analysis Process Designer (APD).
Figure 1 shows the checks that are available with program ZBW_ABAP_ANALYZER, which is made available by implementing SAP Note 1847431 to SAP BW and then executing the program via transaction SE38.
This screen provides the many object categories against which the analysis should be performed. The subsequent tabs (e.g., Chains, Transformations, Transfer Rules, Update Rules, Planning, and APD) can be used to filter the analysis further by restricting it to specific SAP BW object IDs, such as specific transformations, update rules, and transfer rules, among others.
The most common issues highlighted by program ZBW_ABAP_ANALYZER are related to a lack of best-coding practices on table selections, such as look-ups of master data tables or other transactional tables within SAP BW, as well as the use of the “Select for all entries” statement.
Another common example of errors identified by program ZBW_ABAP_ANALYZER is the failure to apply the concept of internal tables at the start-routine level to support enriched look-ups performed at the field level. Without the assistance of internal tables of a start routine, the system is forced to perform database selects every time it processes a record within the data package to complete the field-based look-up routine. In other words, the application keeps knocking the database door as many times as the number of records contained within the data package, which translates into a sub-optimal loading performance.
Even though SAP HANA is an in-memory database with faster response times than other conventional databases, the repetitive retrieving and passing of data between the database and the application adds to the overall duration of the transformation process and reduces performance. It is much more efficient to identify the table fields required for look-up enrichment of records and to pre-load these values as internal tables during start-routine execution. This means one database select instead of multiple, repetitive database selects during a transformation process.
The content then becomes available as a pre-loaded internal table that can be accessed when a field routine is performed. The field routine reads the data from the pre-selected internal tables, and no further database selects are required.
The codes in Figure 2 are examples of a field routine flagged by program ZBW_ABAP_ANALYZER for enhancement.
Method 2: Using the Code Inspector Tool (Transaction Code SCI)
The Code Inspector tool can be used to identify ABAP code corrections required as part of a migration of SAP BW to SAP HANA. This should be done as a pre- and post-migration activity. Running Code Inspector as a pre-migration step helps to identify non-Unicode compatible code, if Unicode conversion is a required part of a database migration. Running Code Inspector as a post-migration step is especially helpful in identifying ABAP programs that contain, for example, BW Accelerator (BWA)-redundant sections.
Code Inspector can be accessed via SAP Menu > Tools > ABAP Workbench > Test > Code Inspector: Inspection, or by executing transaction code SCI (Figure 3).
If the prior SAP BW landscape included BWAs, this post-migration syntax-check step typically returns errors around Data Dictionary elements with technical names having the prefix RSDDTREX. The reason for this is simple: SAP HANA replaces BWA and these Data Dictionary elements are no longer available. You can get a list of Data Dictionary elements with prefix RSDDTREX by executing transaction code SE11 in SAP BW associated to SAP BWA, and searching for tables with the technical name RSDDTREX*. The resulting match-code list should be similar to the one shown in Figure 4, which shows the dictionary elements that are no longer available after migration of SAP BW to SAP HANA.
The usual course of action in cases like this is to decommission programs or code sections within SAP BW that are directly related to BWA. This can be achieved, for example, by having a developer comment out sections of existent ABAP code that reference any of these elements.
Method 3: Using Standard Structure RRRANGESID
Prior to the release of SAP BW 7.4, SAP BW InfoObjects-type characteristics were restricted to 60 characters. With the release of Support Package 2 (SP2) for SAP BW 7.4, this restriction was expanded to accommodate up to 250 characters. SAP made this possible by changing the definition of domain RSCHAVL, from data type CHAR and length 60, to data type SSTRING and length 1333.
When changes are made at the domain level, all related fields are impacted. This includes two fields of structure RRRANGESID: the LOW and HIGH fields, as shown in Figures 5 and 6.
Why are these changes to structure RRRANGESID so important? Well, custom reporting variables on queries are supported via enhancement RSR00001 (BI: Enhancements for Global Variables in Reporting), where the use of range expanded around characteristic values such as fiscal period or calendar month ranges are very fairly common. These ranges are internally related to the HIGH and LOW fields of structure RRRANGESID at run time. The HIGH and LOW fields correspond to nothing else than to the From and To fields available as report filter selections for users on SAP BW query variable selection screens.
The changes to structure RRRANGESID are therefore intrinsically related to SAP BW queries that rely on custom exit variables. The limitation that arises is that data type SSTRING, now referenced by domain RSCHAVL, does not allow for the use of offsetting and length specification. This means that if an offsetting technique is used by a custom exit variable then this variable simply errors out. Any query making use of such a custom variable becomes not operational. Therefore, as part of the post-migration activity, a detailed syntax check is required on enhancement RSR00001. If an offset issue is present, you see an error message like the one shown in Figure 7.
The solution for this is to modify the code by first offsetting the value as desired to a local variable, and then assigning the result to structure RRRANGESID fields LOW and HIGH, instead of trying to offset the fields LOW and HIGH directly.
An example can be seen in Figure 8. In this case, the original code would restrict a query to the first day of the month and year selected by a report user.
The offset highlighted in Figure 8, however, is no longer allowed on SAP BW 7.4 SP2 and later due to references to data type SSTRING. The workaround in this case would be to apply an indirect offset. This can be achieved by first performing the offsetting with the assistance of a local variable, LV_DATE in this example, and then transferring the offset value to parameter l_s_range-low of the routine. Figure 9 demonstrates this approach.
IF i_step = 2.
READ TABLE i_t_var_range
WITH KEY vnam = ‘DATE1’
INTO ld_s_var_range.
IF sy-subrc = 0.
MOVE ld_s_var_range-low TO: l_s_range-low, l_s_range-high.
** Begin of 7.4 Adjustment
LV_DATE = l_s_range-low.
LV_DATE+6(2) = ’01’.
l_s_range-low = LV_DATE.
* Commented out as part of upgrade
* l_s_range-low+6(2) = ’01’.
** End of 7.4 Adjustment
l_s_range-sign = ‘I’.
l_s_range-opt = ‘BT’.
CLEAR e_t_range.
APPEND l_s_range TO e_t_range.
ENDIF.
ENDIF.
Figure 9
Indirect offsetting performed with the assistance of a local variable
