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
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
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.
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,
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
- Eliminate all language constructs based on memory layout assumptions
in general, and on the "one character, 1 byte" assumption
- Offer new, more abstract language constructs as a replacement wherever
- Provide the highest possible degree of compatibility to the pre-Unicode
- 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
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
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
DATA: il TYPE i. i2 TYPE i3 TYPE i.
FIELD-SYMBOLS: +4 TO .
Assign il TO .
DO 3 TIMES.
WRITE . ASSIGN +4 TO .
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 .
|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
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
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,
- 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)
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
- 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
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
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.
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.
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
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
||If the target structure is longer,
fields will be padded with initial values that are also within inner
||If the target structure is shorter, the last field a
the end will be truncated.
|Useful Additions to EXPORT and IMPORT Commands
Some of the more prominent changes in the 6.10 programming infrastructure
- 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
- 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.
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
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
- Definition of exception classes in an inheritance relationship
- Different compile time and runtime options for different kinds of
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
|DATA xref TYPE REF TO cx_root.
" protected code
CALL METHOD o1->m1.
CALL METHOD o1->m2.
... " handle exception cx_my_application
CATCH cx_root INTO xref.
... " handle other exceptions
RAISE EXCEPTION TYPE cx_some_exception
EXPORTING previous = xref.
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
- 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.
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.
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
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
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.
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
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
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.
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
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.
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.
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
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
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
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
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,
14 Previously called "development classes."