GRC
HR
SCM
CRM
BI


Article

 

ABAP 6.10: New Unicode-Enabling Features, Plus a Whole Lot More!

by Karl Kessler | SAPinsider

July 1, 2001

by Karl Kessler, SAP AG, and Andreas Blumenthal, SAP AG SAPinsider - 2001 (Volume 2), July (Issue 3)
 

     Over the past 10 years, the ABAP language and runtime system has been the basis technology for the business applications that run on R/3 systems. ABAP has served the R/3 environment well over the years, evolving from a 4GL programming environment to a full-blown object oriented programming language that covers the rigorous requirements of client/server programming with database access based on SQL, sophisticated GUI interaction based on windows controls, and powerful application services based on a virtual machine approach. But SAP isn't resting on its R/3 laurels.

     SAP is now a dominant player in the business intelligence, customer relationship management, and e-business arenas. The demand for collaborative, Internet-driven, global business solutions introduces new programming requirements, and the ABAP you find at the core of these products with Release 6.10 has been significantly enhanced to support those requirements.

     One of the most significant enhancements by far is its multilanguage capabilities, made possible by Unicode enabling the SAP Web Application Server (the 6.10 successor to the Basis system).

Excellent internationalization support has always been one of the great strengths of the SAP system, which can be run today in languages representing businesses in virtually all parts of the world. Multilingual support in a single SAP system, though, has been tricky, requiring that all the languages the system needs to support use the same character set. But to meet the demands of today's rapidly growing global marketplace, what if you need to use both German and Japanese, Chinese and Thai, or Spanish and Russian? The general solution is called Unicode: the self-descriptive representation of textual data for different languages in a single character set that includes all characters of these languages.

     Unicode-enabling the entire SAP Web Application Server was one of SAP's main development goals for Release 6.10. With this release, the SAP Web Application Server can be used as the technological basis for Unicode-enabled applications.1 Now that the SAP Web Application Server is Unicode-enabled, you can also Unicode-enable your ABAP programs.

     ABAP 6.10 offers some significant benefits to developers, whether you are part of a multinational corporation or not. The Unicode support accompanies other enhancements that extend ABAP's programming capabilities. But beyond this, there is a broader benefit: better programs. If you are a programmer developing or adjusting ABAP programs for Release 6.10 - even if a Unicode migration is not yet in sight - you should absolutely Unicode-enable your programs, if for quality assurance reasons only. Stricter static and dynamic Unicode checks, along with the need to use language constructs at a higher abstraction level, mean that Unicode-enabled ABAP programs are, simply put, more secure: they can be better read, maintained, and enhanced. And learning about Unicode now can help you make important preparations for a subsequent Unicode migration - simply by avoiding non-Unicode-enabled language constructs in your current programming.

Unicode and Non-Unicode Using a Single Code Basis

The good news is that based on SAP's experience during its own Unicode migration of existing ABAP applications, this process does not have to be very time consuming. Even for major software systems written in ABAP, it will take roughly one week on average to make them Unicode-enabled.2 And although Unicode-enabling its software was SAP's central development goal for Release 6.10, customers will not be obliged to migrate to Unicode simply because they need 6.10 functions.

     In fact, SAP had two main goals for its Unicode strategy: first, to allow customers to migrate existing ABAP code, and second, to have one and the same code basis for both Unicode and non-Unicode systems. To that end, Unicode-enabled ABAP programs are executable under both Unicode and non-Unicode systems, and have the same semantics in both environments.

TIP: There is no guarantee that a Unicode-enabled ABAP program will behave the same in both Unicode and non-Unicode systems. For instance, if a program is designed to respond differently depending on the number of bytes per character, then undoubtedly the results in a Unicode environment will differ from those obtained in a non-Unicode environment. However, for ABAP programs that do not contain these types of low-level queries, to a large degree, the strategy adopted by SAP is likely to ensure that Unicode-enabled ABAP programs show the same runtime behavior in both environments.

     In other words, two code bases do not have to be maintained to create applications for both environments with ABAP. As a general rule, all Unicode applications can be operated as non-Unicode applications, and apart from special interface coding, Unicode applications normally run smoothly in non-Unicode environments without requiring modification.

If you are a programmer developing or adjusting ABAP programs for Release 6.10 --even if a Unicode migration is not yet in sight -- you should absolutely Unicode-enable your programs, if you quality assurance reasons only. Stricter static and dynamic Unicode checks, along with the need to use language constructs at a higher abstraction level, mean that Unicode-enabled ABAP programs are, simply put, more secure: they can be better read, maintained, and enhanced.

Unicode-Enablement: New Programming Techniques and an Investment in Quality

Why are existing ABAP programs not inherently Unicode-enabled? The main reason is that ABAP programs might be predicated on assumptions, explicit or implicit, concerning the memory layout of the data. Many ABAP programming techniques are based on the assumption that one character corresponds to 1 byte in memory. Unicode-enabling ABAP therefore involves these four tasks:

  1. Eliminate all language constructs based on memory layout assumptions in general, and on the "one character, 1 byte" assumption in particular.
  2. Offer new, more abstract language constructs as a replacement wherever necessary.
  3. Provide the highest possible degree of compatibility to the pre-Unicode world.
  4. Ensure that Unicode-enabled programs have the same semantics under both Unicode and non-Unicode environments.

     Since the goal is to preserve old code where possible, and use the same code basis for both Unicode and non-Unicode programs, it is not enough to simply introduce a new Unicode data type against which to program explicitly. So SAP's Unicode strategy is to handle all character-like data types available in ABAP3 identically, and, in a Unicode system, to map each of these character-like types to Unicode.

     In Unicode-enabled ABAP programs, byte-like types4 (which can have dif-ferent functions in conventional ABAP code, where X field content might be handled as characters, numbers, or byte strings) can no longer be used for stor-ing characters. Therefore types X and XSTRING do not belong to character-like types. However, structures that exclusively consist of character type components of fixed length are treated like C fields under Unicode. In this sense, only purely character-like type structures belong to character-like types under Unicode.

     Again, the benefits go beyond multi-language support. Programs that avoid assumptions about memory layout and use higher-level language constructs contain fewer errors and are easier to understand, maintain, and enhance. Unicode migrations often reveal code sections that have always been a problem - code that has worked more or less only by accident, or even triggered errors under certain conditions. As a result, Unicode-enabling not only gives you the benefits of Unicode itself, but is also an investment in the quality and maintainability of your ABAP programs.

The First Steps Toward Unicode Migration

Unicode-enabling ABAP programs does not require you to immediately set up a real Unicode system - this is actually the last step in Unicode migration. While we won't cover Unicode migration in detail here, it's helpful to understand the two preliminary steps to Unicode-enabling your programs with Release 6.10.

     First, enable the stricter Unicode checks in the non-Unicode 6.10 system at the level of individual programs. You can do this either manually, or via transaction UCCHECK. To enable these checks, set the program properties to ensure that the more rigorous Unicode restrictions apply both statically and dynamically in the non-Unicode system. It is thus possible to migrate single programs one-by-one to Unicode.

     Second, in the non-Unicode system, set a system-wide switch that allows the execution of only those ABAP programs for which the stricter Unicode checks are enabled (SAP profile parameter abap/unicode_check=on). When you set this SAP profile parameter, all required programs must have been adjusted. Error messages will indicate which programs still need adjustment.

     Only after all programs have been adjusted in the non-Unicode system and executed once for testing5 is the last step performed - the Unicode migration itself, i.e., the setup of a real Unicode sys-tem where all data is migrated to Unicode.

Implications of Unicode-Enabled ABAP: Three Examples

In this section, we cover a few of the implications involved in stricter checks and new language constructs of the new release.6

Example 1: Offset/Length Access to Elementary Fields and Structures

Offset/length access to elementary fields works without problems under Unicode. The access semantics are the same under Unicode and non-Unicode, since offset and length specifications are interpreted as character specifications, (in the case of character-like fields) or byte specifications (in the case of byte-like fields).

     But the situation is more difficult when it comes to offset/length access to structures - where character type, byte type, and numeric components (as well as alignment gaps caused by substructuring) may lay side by side in random order. Previously, offset/length access to flat structures7 in ABAP was possible in any case. The expression struc+off(len) simply specified the length len in bytes starting at the offset off in the structure struc. Because in the pre-Unicode days platform-dependent field lengths did not exist and one character always corresponded to 1 byte, this type of offset/length access at least addressed the same memory area in a platform-independent manner.8

     Now, a character can consist of 1 byte in a non-Unicode environment and 2 bytes in a Unicode environment. So the question arises as to what struc+off(len) means:

  • With the byte-based response, len indicates length in bytes, starting at byte offset off. In this case, offset/length access would select different memory areas in a Unicode and a non-Unicode system. This would violate the principle of identical semantics in both systems, and is therefore not viable.
  • With the character-based response, len indicates length in characters starting at character offset off. In this case, offset/length access would select the same memory area on all platforms only if the structure struc is purely character-like for the total length identified - that is, for the length off+len.

     Therefore, in a Unicode-enabled program, offset/length access struc+off(len) to structures is only valid if structure struc starts with a purely character-like section of at least off+1en characters. If the Unicode checks are enabled, the offset or length access to structure sections that are not purely character-like are rejected as an error.

Example 2: Addressing Beyond Field Borders - ASSIGN with RANGE and INCREMENT

Offset/length access also plays an important role when it comes to assigning field symbols using ASSIGN src TO . Until now, special rules applied to the source field position src:

  • In the case of offset/length access src+off(len), addressing was possible beyond the field border of the source field src.
  • In the case of offset access without length specification, such as src+off, the source field length was adopted unchanged, which means that addressing was made in the length of the specified offset off beyond the field border of the source field src.

     The semantics for access that goes beyond field borders depend on the memory layout of the source field's "environment." When Unicode checks are enabled, this type of access is generally forbidden. You can get around this using the new RANGE addition for ASSIGN. If the source field environment is explicitly declared using RANGE, addressing beyond field borders is still allowed for ASSIGN - but even then, only within a data structure.9

     Listing 1 illustrates how the new RANGE addition is used together with the ASSIGN-INCREMENT variant for the type-adequate incrementing/decrementing of field symbols, contrasting the old programming style with the new. The old style allowed positioning beyond field borders, and only segment border violations were forbidden - the system terminated immediately with a runtime error. The new style generally forbids even field border violations.10


FORM oldStyle
	DATA: il TYPE i.  i2 TYPE i3 TYPE i.
	FIELD-SYMBOLS: +4 TO .
	Assign il TO .
    DO 3 TIMES.
       WRITE . ASSIGN +4 TO .
    ENDDO.
END FORM.

FORM NewStyle.
    DATA: BEGIN OF s.
       	  il TYPE i.i2 TYPE i. i3 TYPE i.
       END OF s.
    FIELD-SYMBOLS:  TYPE i.
    ASSIGN s-il TO  RANGE s.
    DO 3 TIMES.
       WRITE .  ASSIGN  INCREMENT TO 1 TO .
    ENDDO.
END FORM.

Listing 1

Pre-Unicode Programming Style vs. Unicode-Enables Style

Example 3: Symbolic Access to Substructures - Named Includes

In many cases, offset/length access to structures, as well as assignments and comparisons between incompatible structures, could be avoided altogether if it were possible to symbolically address parts of a structure (that is, groups of juxtaposed components).

     Since Release 3.0, ABAP has allowed developers to define nested data structures and thus symbolically address substructures. This alone is not sufficient, however. In many cases, ABAP data structures are used as carrier structures for database tables, and the first normal form for relational databases specifies that columns of database tables must be atomic (that is, not structures themselves). Nested data structures therefore cannot be used for communication with a common relational database - exactly the type on which the SAP system is based.

     The way out of this dilemma is to make data structures appear to the database as structures with atomic components, but to handle these structures internally in the program as nested data structures. We achieve this by using include technology to set up structures. In 6.10, these includes are assigned names, which makes it possible to address all fields of an included structure using this group name.

     The named includes approach is already available in ABAP - and, even more important, in the Dictionary - as of Release 4.6. Symbolically addressing substructures of database tables, even in 4.6 systems, is an important preparation for Unicode-enabling programs.

Beyond Unicode: Further Enhancements to ABAP

In addition to Unicode and web-enabling11 support, ABAP 6.10 offers further enhancements that extend ABAP programming capabilities, including:

  • Interfaces and infrastructure: New file I/O interface and enhancements to support a wide variety of ABAP sources
  • Object technology: A brand-new class-based exception-handling scheme and support for friend classes
  • Object services: Transaction and persistence services for ABAP Objects12
  • Dynamic and generic programming: New generic types and support for generic and dynamic implementation techniques
  • Tools: New tools are available to thoroughly test these new technologies

In the following sections, we will cover these extensions of ABAP's capabilities.

Interfaces and Infrastructure

In any Unicode environment, handling files or data export or import becomes a critical task - and not only because data is stored and exchanged differently in Unicode-based systems. It is also highly likely that you will find plenty of legacy data that must be processed in a Unicode fashion. Ideally, from an ABAP programmer's point of view, applications should not be required to determine whether a character is stored in 1 or 2 bytes and which is the correct byte order. However, since files and export data can be manipulated in a binary way, some language features are essential to mapping between character representations and encodings:

     Adapting the file interface to Unicode has led to stricter validity checks for operations on files, and thus dramatically reduces the potential for error.

     In pre-6.10 releases, the file interface was characterized by a large number of automatic mechanisms intended to simplify programming for developers. Instead, they often led to a large number of implicit assumptions, which in turn led to faulty code. Now, checks are stricter and the programming is less "implicit," which means that the code is considerably more robust.

     For example, in ABAP 6.10, files are no longer opened automatically, the type of access (such as FOR INPUT) must be declared when the file is opened, and the system ensures that you cannot violate the access type.

     In addition, Unicode now has special requirements for necessary conversions, and three new conversion classes (see "New Conversion Requirements and Classes.")

New Conversion Requirement and Classes

The OPEN DATASET statement has several additions that support access to files in Unicode and non-Unicode environments:

  • Encoding: You can specify the underlying representation using the ENCODING addition.
  • Text mode vs. binary mode: The difference between the two is now clearer. In text mode, you can write only character type data. If you want to write binary data, such as the memory layout of structures containing type I fields, you must choose binary mode.
  • Legacy [text | binary] mode: The old modes are also available, but both modes have been enhanced, so there is no need to convert explicitly using TRANSLATE FROM/TO CODE PAGE or NUMBER FORMAT. Instead, the data is converted automatically at the interface, so there is no invalid data (or data that could be misinterpreted) in variables.

Three new classes have been introduced for arbitrary data conversion whenever the built-in capabilities of the various ABAP statements are not sufficient:

  • CL_ABAP_CONV_IN_CE to convert binary data to valid ABAP data objects.
  • CL_ABAP_CONV_OUT_CE to convert ABAP data objects to binary data, so they can be output as binary files.
  • CL_ABAP_CONV_X2X_CE to convert different binary data representations using text in different character set and numeric data in different number formats.

Width of ABAP Sources

Before ABAP supported Unicode, the width of ABAP sources was limited to 72 characters per source line, and many ABAP programs - generated at runtime and loaded immediately thereafter - still rely on this structure. Hence, it took some effort to support "wide sources" both in the ABAP editor and in the database. Technically speaking, an ABAP program is now treated as a table of strings, and all programmatic interfaces now support this new data structure.

     Another restriction in this area has also been lifted: the ABAP compiler now reports more than one error if you select this option in your personal settings. Although you will now yield more error messages, the documentation that appears when an error is detected explains the differences between Unicode and non-Unicode errors in great detail.

Reading and Changing File Attributes at Runtime

Since there are stricter checks for file access at runtime, the programmer needs to know the file's attributes as specified in the OPEN DATASET statement. The GET DATASET statement returns this information. For the current read or write position (which enables you to return to a spe-cific position later), use GET DATASET's counterpart, the SET DATASET statement. You can also use this statement to change other settings specified in the OPEN DATASET statement.

Export/Import

Instead of using files for intermediate storage of structured data, ABAP has long provided memory and buffering areas, both on the application server and on the database level. You can use the EXPORT and IMPORT commands to exchange data between your program and these areas. With ABAP 6.10, refinements regarding available storage media and storage space include two new storage areas: DATA BUFFER and SHARED MEMORY. The first is implemented as an XSTRING variable, whereas the second provides access to shared memory resources on your application server.

     To minimize memory (and disk!) space, the EXPORT command uses compression when flushing to shared memory or to the database, but you can switch off this feature. EXPORT to databuffer is always done uncompressed by default.

TIP: Previously, the SHARED BUFFER medium was managed by the system in an LRU fashion, but now it is up to you to clean up shared memory after use.

     Some new features also help when working with EXPORT and IMPORT, as listed in Figure 1.

     In addition, with ABAP 6.10, data set files larger than 2GB can now be addressed.

IGNORING STRUCTURE BOUNDARIES This ignores the structure boundaries, so that if the source and target structure do not match, only the layout at the leaf level is important
ACCEPTING PADDING If the target structure is longer, fields will be padded with initial values that are also within inner structures.
ACCEPTING TRUNCATION If the target structure is shorter, the last field a the end will be truncated.

Figure 1

Useful Additions to EXPORT and IMPORT Commands

Programming Infrastructure

Some of the more prominent changes in the 6.10 programming infrastructure are:

  • Precompiled headers: The heavily used header information of ABAP classes, interfaces, and type pools is now compiled and stored intermediately. This saves compilation time if you reuse ABAP classes, since parts of the symbol table are persisted. Pre-compiled headers also accelerate the construction of more accurate "where-used" lists in the Development Workbench, which will be based on a syntax check, rather than a scan.
  • SCAN ABAP-SOURCE command: The SCAN command offers a more flexible tokenization of the supplied character stream for analyzing ABAP statements.
  • Separated database LUW during generation: If a running transaction encounters an ABAP program that needs to be recompiled on the fly, the ABAP program cannot be committed to the database, since the current trans-action would commit as well, and could lead to database inconsistencies. At the same time, other transactions running the same program will also be blocked, which could drive the system to a standstill. When compiling ABAP programs with 6.10, the system tries to find another dialog work process to compile the ABAP program in a separate database LUW, and sends a corresponding message to the SAPGUI status bar.

New Features to Support Object Technology

As of Release 4.5 and the introduction of ABAP Objects, object technology has been widely used in ABAP programs. ABAP Objects were chosen to implement all the control classes that make up the EnjoySAP look and feel, and have proven their robustness in pure application scenarios like the Financials server. While 4.x technology supports object-oriented development projects of any size, Release 6.10 adds some helpful features for working with objects:

  • A new exception concept based on classes
  • Support for friend classes
  • Object services for persistence and transaction management

     While the first two techniques are standard in most object-oriented programming languages, the third leverages application development, as contents from the underlying relational database can be treated from an application programmer's point of view as objects without losing the database consistency and integrity.

Handling Exceptions

Exception handling has been previously available to a certain extent - mainly to support return code handling in a more symbolic way. You could raise exceptions in function modules and handle them in the calling layer, or catch ABAP runtime errors by surround-ing code with a CATCH-ENDCATCH block.

     Of course, this is still supported in 6.10, but its limitations become apparent in comparison to the new object-oriented exception concept, which offers:

  • Clean separation between normal and error-handling code using the new TRY-CATCH block
  • Uniform handling of system-based and application-defined exceptions
  • Bundling of error handlers
  • The ability to catch exceptions raised on arbitrary deep invocation levels
  • Definition of exception classes in an inheritance relationship
  • Different compile time and runtime options for different kinds of exceptions

     In an object-oriented environment, exceptions are instances of exception classes defined either by the system or by the application programmer. If an error occurs during the execution of an ABAP program, an exception is created (instantiated). The control of execution is passed to the place where the program tried to execute the code that caused the exception.

     Exception classes are present in the class library in an inheritance relationship starting with class CX_ROOT, which is the base class for all exceptions. Under CX_ROOT you find three different derived classes that control whether the proper handling of exceptions is checked at compile time (CX_STATIC_CHECK), or at runtime (CX_DYNAMIC_CHECK), or whether no check occurs (CX_NO_CHECK). In the third case, an exception is always propagated.

Object-Oriented Exception Handling with ABAP 6.10

DATA xref TYPE REF TO cx_root.
TRY.
" protected code
CALL METHOD o1->m1.
CALL METHOD o1->m2.
...
CATCH cx_my_application.
... " handle exception cx_my_application
CATCH cx_root INTO xref.
... " handle other exceptions
RAISE EXCEPTION TYPE cx_some_exception
EXPORTING previous = xref.
ENDTRY.

 

This code sample demonstrates some of the exception handling features in ABAP 6.10, which include:

  • TRY-CATCH block: In ABAP 6.10, you now must use a TRY-CATCH block for exception handling, which distinguishes between normal and error-handling code. The TRY block contains only the "normal code" to be executed. If an exception occurs, control is transferred to the CATCH block. All data communication necessary to analyze the situation further must be encapsulated in the exception object.
  • Multiple CATCH clauses: You can also specify multiple CATCH clauses if you provide different error handlers for the same TRY block. These clauses must be sorted starting from the most specific to the most generic exception, so that the system can find the most appropriate event handler.
  • RAISING addition: Methods (and forms and functions, for that matter!) should declare the exceptions that can occur during their execution, but they are not handled on their own with the RAISING addition when defining their signature.
  • CLEANUP section: If the system cannot find a suitable handler in a TRY-CATCH block, a subsequent CLEANUP section helps to remove any inconsistencies or to release resources.

After the cleanup, the system will propagate the exception to the next calling level, provided that the called method, form, or function has declared the exception with RAISING. The exception is then said to "pass the method's interface." The propagation is continued until a suitable handler is found. If none is found, or if the exception cannot pass the method's interface due to a missing RAISING addition, the system aborts the current transaction.

Friend Concept

A fundamental principle in object-oriented programming is encapsulation: each object and class defines the scope of its components' visibility to the outer world. While in theory any violation of this rule weakens strict object design principles, in practice there are some classes that are not truly independent and have to cooperate closely. The friend concept can be helpful in these circumstances. This is now supported in ABAP 6.10.

     Because you cannot take friendship (you can only grant friendship to other classes), friend classes can also access your protected and private members. You should carefully look at the impact which friendship introduces. For example, if you grant friendship to an interface, all classes that implement the specified interface will be friends (i.e., they will have access to your non-public members). Also, friendship is not a symmetric relationship. You must grant friendship to both classes if they need mutual access to their members. The friendship becomes even more problematic if you consider inheritance; not only the friend but all of its derived classes automatically become friends. If you want to restrict such access, you should offer friendship only to final classes that cannot be further derived. The friendship offering is not subject to inheritance.

Remote Function Call Protocol

From its early days, Remote Function Call (RFC) has been the main SAP protocol for calling ABAP functionality remotely in a distributed environment both synchronously and asynchronously. In previous releases, RFC technology was limited in argument passing, and only fields, structures, and simple tables were supported. Now with ABAP 6.10, you can pass deep structures as well.

Support for Dynamic and Generic Programming

SAP's applications rely on customization that creates dictionary and program objects (consider, for example, a classification system with categories defined at the customer's site). While many field and type names are not known at build time, they still must be dealt with at runtime in a consistent and high-performing manner.

     For such cases, ABAP now supports a generic programming style with features like dynamic access of an object's attributes, typed data references for dynamically created variables and internal tables, new generic data types, and a more flexible approach to dynamic Open SQL.

     In previous releases, if you did not know the table's name at build time, you could refer to a table's name dynamically by using the variable's name at runtime in parentheses. If you access an object or class attribute dynamically, the same syntax is now used to specify a dynamic class or attribute name. For the time being, ABAP also supports dynamic access to object attributes when assigning a field symbol.

     To further optimize memory resources, you can create variables dynamically and access their contents with data references. Typed data references are allocated with the CREATE DATA statement, and are also supported when iterating over or reading from internal tables. The dereference operator ->* allows you to access the different components referenced by a data reference.

TIP: To the extent possible, assign types to data references to help avoid misinterpretation of stored data. Typed data references are also a good alternative to the use of field symbols.

     Similarly, you can create internal tables dynamically with CREATE DATA, based on a static or dynamically determined line type, without the need to specify a corresponding internal table type in the ABAP dictionary.

     Support for generic programming has been enhanced in ABAP 6.10, with some new generic types - such as SIMPLE, CLIKE, CSEQUENCE, XSEQUENCE, and NUMERIC. Another area of generic programming is dynamic Open SQL, which in previous releases supported dynamic concatenation of SQL queries. In 6.10, the advantages of dynamic Open SQL have expanded:

  • It uses datatype STRING to implement the dynamic parts, rather than using internal tables consisting of CHAR(72) lines.
  • All SQL clauses are now dynamic (FROM, WHERE, GROUP, HAVING, SET).
  • It uses ABAP variables in the dynamic parts of an SQL statement. Instead of concatenating the field values into your SQL clauses, simply supply strings containing field names as you would in static Open SQL code.

New Tools: Coverage Analyzer and Code Inspector

Good tools speed up the development process, especially during software testing. Existing tools, like the ABAP Debugger,13 have been enhanced with Release 6.10. And now, new tools like the Coverage Analyzer and Code Inspector help to leverage the overall quality of your implementation:

Coverage Analyzer

The Coverage Analyzer analyzes the runtime behavior of your system. An administrator starts the Coverage Analyzer, typically at the beginning of a test or maintenance project. In fact, SAP started the Coverage Analyzer at the beginning of the Unicode project.

     The Coverage Analyzer helps you to analyze or detect overall use of ABAP programs, less well-structured code (e.g., large function groups that are rarely called), potentially dead code, and performance options for heavily used code.

     The Coverage Analyzer displays the overall coverage of package SWBM. The Coverage Analyzer collects data from the execution of all loaded ABAP programs, and at the granularity level of ABAP events (AT LINE-SELECTION, form routines, function calls, or method invocations). Information about the invocation of a call unit is appended to a shared buffer on the application server. From time to time, an ABAP batch program collects the data entries contained in the shared buffer and flushes them to the database. The database records contain fields that indicate how often a program was loaded.

     For all programs, function groups, or class pools of a given package,14 the Coverage Analyzer stores the name of their modularization units along with the number of invocations, memorizes the number of dumps and saves the number of calls since Coverage Analyzer startup and since the last reset.

     The Coverage Analyzer displays the collected data (transaction SCOV) in a couple of customizable hierarchies. A typical view starts with the packages that reside in the system. From there, you can drill down to the programs and their respective modularization units, or look at the system from the user or test group perspective. The data is then aggregated into a graphic that illustrates the overall coverage. In a distributed development environment, you can condense statistics from different development systems to offer a unified view of your system landscape.

Code Inspector

While the Coverage Analyzer analyzes the runtime behavior of ABAP programs, the Code Inspector is a new test environment for static checks. You can use the Code Inspector to combine different checks to help ensure syntactic and semantic correctness, and to integrate static performance checks (such as finding "dangerous" SELECT statements that do not use indexes or use where clauses that result in full table scans).

     With the Code Inspector, you can also define inspections that consist of a set of development objects (ABAP programs, function groups, and classes) and a check variant (i.e., some subset of the available test catalog). You simply navigate the test hierarchy and enable/ disable a test, such as extended program check, technical consistency check for tables, or analysis of critical SELECT statements. A fast inspection mode allows you to start a check right away, while for larger test scenarios, you can schedule batch processes to do the work.

Conclusion

As of Release 6.10, ABAP supports the development of collaborative business scenarios over the Internet adhering to open Internet standards such as Unicode, HTML, and XML. Release 6.10 not only brings with it more powerful technology, but many features to ease your daily programming work.

     Most important, with ABAP 6.10 and the SAP Web Application Server, the creation of Unicode-enabled applications and the Unicode migration of existing applications is well supported.

     For more documentation, see Development News on the SAP Service Marketplace (http://service.sap.com) along with the release notes and ABAP 6.10 online documentation.


Karl Kessler joined SAP in 1992. He is the Product Manager of the ABAP Workbench and is responsible for all rollout activities. You can reach him via e-mail at karl.kessler@sap.com

 

 

 

Andreas Blumenthal studied linguistics, mathematics, philosophy, and Jewish studies at the university of Heidelberg, where he received his master's degree in 1985. After two years of research in computational linguistics, he joined SAP in 1987. From the beginning of the R/3 project, Andreas was part of the core team of R/3 technology development and has made substantial contributions to the evolution of ABAP into a modern, object-oriented programming language. Since 1996, Andreas has been the Development Manager for ABAP Language, and since 2000 has been responsible for Business Programming Languages.


1 The ABAP runtime system and development environments historically have been part of the SAP Basis system. Release 6.10 replaces the Basis system with its successor, the SAP Web Application Server. The Basis system, including the ABAP runtime and development environment, has been enhanced with significant Web capabilities - hence the new name for the core system. For more on Release 6.10 and the the SAP Web Application Server, see "From 'SAP Basis' to 'SAP Web Application Builder'" in this issue of SAP Insider.

2 It is worth noting that these are averages. Many developers will need less time, while some will need considerably more - in particular those responsible for highly generic source code or interfaces to the outside world.

3 C, N, D, T, and, as of 4.6, STRING.

4 X and, as of 4.6, XSTRING.

5 You can check on whether all necessary tests have been run after the migration using the new Coverage Analyzer tool (discussed later in this article).

6 Stricter and enhanced language constructs for implementing interfaces to the outside world - file interface, IMPORT/EXPORT - also play an important part in the Unicode migration process. For the sake of simplicity, those language constructs are not considered in the following examples.

7 A flat structure is a structure whose memory is completely managed "inline." Therefore, a flat structure is a structure that contains neither data references, nor object references, nor strings, nor internal tables as components.

8 We won't take into consideration here the old question of whether offset/length access to mixed structures is semantically adequate!

9 In the past, when you specified actual parameters in PERFORM, offset/length specifications across field borders were possible as at the source field position in ASSIGN. If the Unicode checks are enabled, this is also no longer allowed in PERFORM.

10 However, if ASSIGN violates field borders and the Unicode checks are enabled, the system does not terminate with a runtime error, but only sets the field symbol to UNASSIGNED (which can be queried in logical expressions with IS ASSIGNED). This is because: (1) a runtime error would be too harsh a reaction for field border violations. In loop processing, field border violations at ASSIGN without subsequent access to the field symbol may have no serious consequences and (2) setting SY-SUBRC at each ASSIGN is not possible for compatibility reasons.

11 For more information on web-enablement, including support for HTML scripting and XML data conversion and messaging, see "From 'SAP Basis' to 'SAP Web Application Server' " in this issue of SAP Insider.

12 While object services are not covered in this article, information is available at http://service.sap.com.

13 See the article "Software Testing and Development with the ABAP Debugger" In SAP Insider, Apr/May/Jun 2001, Vol.2, No.2.

14 Previously called "development classes."

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ