SAP has provided new and innovative technologies in SAP NetWeaver 7.1 and acted on the suggestions and requests of ABAP developers to improve existing and proven features.
Internal tables with secondary keys
In ABAP, internal tables fulfill the function of arrays. They are often used to process data retrieved from the database in the main memory of the application server. Internal tables have a fixed type (STANDARD, SORTED, or HASHED), and until now, developers have been able to define only a single primary key (UNIQUE or NON-UNIQUE) for optimizing table access. This limitation has long been a thorn in the side of performance-aware developers. Very often the type and the primary key are not ideally suited for accessing the data. A good example is when the data must be accessed by information that is not a constituent of the primary key.
The problem of how best to access data in datasets is not new to computer scientists. Database management systems (DBMS), for example, have long solved this problem by using secondary indexes. Simply put, a secondary index is a way to access database records effectively by using information other than the primary key on the database. ABAP developers have long requested something similar for internal tables, and some creative developers have even implemented complicated constructs to simulate secondary indexes for internal tables.
The ABAP programming language now provides direct support for secondary indexes on internal tables. They are called secondary keys. In addition to the primary key, up to 15 secondary keys can be defined for all types of internal tables. Secondary keys can be SORTED or HASHED. Sorted secondary keys can be either UNIQUE or NON-UNIQUE, but hashed secondary keys are always UNIQUE. Syntax warnings are issued if duplicate or conflicting secondary keys are defined.
When table data is accessed, the secondary key to be used must be specified explicitly – either statically or dynamically. Otherwise, the primary key is used. This is an important difference compared to secondary indexes of database tables. Since there is no guaranteed order of retrieval of the records from the database (assuming ORDER BY is not used), a database optimizer can choose the secondary index best-suited to accessing the data. This approach is impossible with internal tables.
Choosing the best-suited secondary key dynamically would alter the order in which the data is retrieved. That would make secondary keys unpredictable and cause unwanted side effects in ABAP applications. For that reason, no optimizer exists for secondary keys. However, to avoid leaving developers completely in the dark, a syntax warning is issued at compile time if a better-suited key was identified.
Secondary keys were introduced to boost internal table performance, but improper use can cost a significant amount of memory for internal management. Excessive updates of the secondary keys can even negatively affect performance. Unique secondary keys are updated immediately via a direct update; non-unique secondary keys are created or updated only when the key is used – with a “lazy” update.
The optimal scenario for the use of secondary keys is a large internal table that is created only once and that is rarely modified. Non-unique secondary keys are the best choice if the primary requirement is for fast read access. Unique secondary keys are often used to automatically enforce uniqueness as a semantic constraint.
Business applications are becoming more and more dependent on string processing and string generation because they are required for generating program code or data that is exchanged with markup languages like XML.
Although ABAP already offered a set of string processing features before SAP NetWeaver 7.1 (some dedicated statements, some logical operators, and use of regular expressions), the handling of character strings was always a bit tedious. It was comparable to using the ADD statement instead of arithmetic expressions for calculations. Furthermore, real support for working with the modern STRING data type was sorely missed in many places. In particular, the manner of converting and formatting the contents of any data type to a string using the WRITE TO statement, historically stemming from traditional list processing, could not be used for the target type string.
This situation has thoroughly changed with SAP NetWeaver 7.1. The newly introduced string expressions and an extensive set of string functions have revolutionized string processing in ABAP.
String expressions consist of:
* String operators, in particular the new && concatenation operator
* String templates that take literal text and embedded expressions with formatting options and convert them to a string
The figure shows an example for using string expressions. Two string templates are concatenated to a text symbol TEXT-SYM to form the input for a method call. The string templates are defined between vertical bars. They consist of an arbitrary sequence of literal text and embedded expressions that are defined between curly brackets. The embedded expressions consist of regular ABAP expression syntax combined with format options.
In the first string template, the sum of two numerical returning parameters is formatted as a monetary amount. If the text symbol TEXT-SYM stands for “amount”, the variable CUR contains “USD”, method GET_AMOUNT returns the value -100, and method GET_TAX returns -16, then the parameter passed to the output method is “amount: -116.00 USD”. It is not even worth thinking about the amount of coding needed to get the same result with the former string processing capabilities of ABAP.
In addition to string expressions, in SAP NetWeaver 7.1 ABAP also offers a large set of new string functions. The functions generally replace earlier string processing statements. They can be used at various operand positions and – of course – in combination with string expressions. The built-in TO_UPPER function converts the contents of a string to uppercase. The result is then used in a logical expression that compares the converted string to a constant.
As another example, the MATCHES string function is a predicate function that returns a truth value. Predicate functions can be used directly as logical expressions. Another distinctive feature of the MATCHES function is that it accepts more than one argument. The function checks if the string passed in the first argument matches the regular expression passed for the formal parameter REGEX.
The new string expressions and the new string functions – only a few of which are treated here – simplify string processing in future ABAP programs, making them more robust, easier to read, and more maintainable.
Every developer has surely dreamt of debugging ABAP software automatically or walking through the execution of an ABAP program while the debugger hides any uninteresting code. These are only two of the many new features the ABAP debugger offers in SAP NetWeaver 7.1.
The new scripting engine in the ABAP debugger allows developers to control the debugger by writing a small program that is triggered during execution of the application. The script can be triggered manually or automatically with each debugger single step or when a break point or watch point is reached. Writing scripts is easy. Developers don’t have to learn a new scripting language to control the debugger.
Debugger scripts are written in ABAP and can access the same information about the debuggee as the debugger itself by using the debugger API. Scripts can be used to change program data, manipulate the program flow, investigate memory consumption, implement stateful conditional breakpoints, or write information to a trace file. The integration of the scripting engine in the ABAP workbench lets developers transport the debugger scripts and their trigger points just like other repository objects.
MyZone debugging is a new feature. It allows developers to specify their “zone of interest.” They can define their own software layers, so that when they walk through the execution of the program, they jump from layer to layer instead of taking single steps through masses of foreign code until they reach the code they are interested in. Layers are defined on the basis of packages, programs, classes, or function modules. Developers can customize the debugger’s behavior to stop program execution when a layer is reached or exited. Layers can also be hidden so that the debugger will stop only in visible layers.
Both debugger scripting and MyZone debugging are new features that greatly enhance the productivity of ABAP developers.
ABAP was once called ABAP/4. The name underscored the perception of ABAP as a fourth-generation language, a programming environment with tailor-made concepts for special purposes. The purpose of ABAP is to develop business applications. Although the “/4” has disappeared from its name, SAP is still deeply dedicated to providing a platform suitable for implementing complex business applications that are robust and perform well, in the easiest possible manner.