Karl Kessler,
SAP AG |
While
much of the development news from SAP in
2003 was focused on Java, the year also brought
lots of new benefits for ABAP developers.
SAP Web Application Server (SAP Web AS) 6.40,
to be released to customers in 2004, touches
on and enhances almost every aspect of ABAP
development — from
the language itself, to tools, to application
structure and design, to monitoring. This
article introduces just some of the new features
targeted for SAP Web AS 6.40, including:
New possibilities for structuring and accessing data with shared objects.
Shared objects allow for copy-free access to complex ABAP variables in
shared memory.
A tool to analyze memory consumption in long-running transactions such
as a customer interaction centers.
A redesigned and enhanced Debugger tool.
The new ASSERT statement.
Capabilities for activating multiple assertions and breakpoints with a
single command.
ABAP Language Enhancements: Shared Objects
Shared objects, as the name suggests, are a new kind of ABAP object
that allow objects to be kept and managed in shared memory. They provide
a dramatic change for structuring and accessing data in ABAP applications.
With the SAP R/3 application server (the classic ABAP runtime environment),
shared memory was primarily used to manage the ABAP program cache and
user session information (roll area1), as
well as a variety of buffers for the central data — such as customizing
tables, factory calendar, etc. — that is shared among applications.
For developers, programmatic access to shared memory was quite limited:
ABAP statements EXPORT TO SHARED BUFFER or EXPORT TO SHARED MEMORY only
allow for value-oriented data types (fields, flat structures, internal
tables) and make for some tedious tasks during application development
(e.g., displacement of shared data in the buffer).
Consider, for example, how you would set up a complex catalog for cross-application
use. In typical ABAP development, this would require the export (i.e.,
copy) of data from the roll area of a “writer” transaction
to shared memory. Since only flat data types are supported, the catalog
object needs to be split up into tables, structures, and fields. Later
“reader” transactions must import (i.e., copy) the data back
to their roll area. In other words, a reader transaction can only access
information by copying the data from the shared buffer to its own roll
area.
To overcome these limitations, SAP Web AS 6.40 introduces shared
objects for ABAP. Now, rather than managing a collection of flat
data structures and copying information between transactions, you can
use objects that include references to several other objects, stemming
from a root object (see Figure 1). These objects
allow you to store ABAP variables of any kind in shared memory for copy-free
read access.
 |
Figure
1 |
Use Shared Objects to Provide Stable, Copy-Free Access
to Central Data |
With shared objects, you can:
- Reduce copy operations, since objects are directly accessed in shared
memory and can be shared among different transactions. You’ll
find a good example — in fact, one of the early pilots of shared
objects — in the 6.40 Workbench itself, which was built using
shared objects. Navigation of the Workbench is now 100 times faster
at first access and saves 3 MB session memory per user.2
- Avoid data inconsistencies, especially in data structures spread
across multiple internal tables where managing and maintaining foreign
key relationships between tables can be cumbersome.
Defining Shared Memory Areas
Shared objects are managed in shared memory areas that you
define at design time with transaction SHMA. Each shared memory area manages
one or several area instances.
Each shared memory area instance is self-contained — no references
to other area instances or variables of the roll area are allowed. When
you create a shared memory area (CL_SANA_SHM_AREA in Figure 2),
you specify a class name to be generated that inherits from the system
class CL_SHM_AREA. When you define a shared memory area, you must specify
an associated root class. A shared object is always accessed by a root
object that can contain references to subordinate objects.
 |
Figure
2 |
A View into a Shared Memory Area with the Shared Memory
Monitor |
Creating Shared Objects
To create shared objects, simply use the CREATE OBJECT statement with
an AREA HANDLE addition, and make sure the underlying class is “shared-enabled.”
The area handle allows you to access the object graph starting at the
root object.
In a typical code sequence, for example, you first attach the running
transaction to a shared memory area in order to gain a handle. Then, you
create an object in shared memory associated with that handle and make
it the root object for the shared memory area instance. From there, you
would simply use ABAP Objects code to manipulate the shared object as
you would any other object.
There is also a new shared memory monitor (transaction SHMM, shown in
Figure 2), which allows you to view all shared memory areas and instances
created therein (e.g., see any locks or navigate the content).
Additional Information on Creating
and Updating Shared Objects
Attach and Detach with Handles
If a transaction wants to access a shared object,
it creates a handle in the roll area for identification
and attaches to the shared memory area instance containing
the shared object. When you detach from the shared memory area instance,
the shared object becomes unavailable, and you must indicate whether
you want to commit or roll back your changes.
Locking Prevents Read/Write Conflicts
Simultaneous access of multiple readers is managed
through read locks. Shared objects can be written or updated with
locking. When a writer wants to update or insert a shared object,
the complete area instance is locked.
Note!
The coarse-grained locking concept for shared objects works
when the frequency of updates is low compared to read access
(for example, a complex catalog of objects where updates are
done on a daily basis). For this reason, OLTP access would
not be a good candidate for a shared-objects approach. |
Advanced Features with Shared Objects
Shared objects include advanced features, such as
versioning, which can be used to better indicate the status of shared
objects. Typical version states are “UNDER CONSTRUCTION”,
“ACTIVE”, “OUT-OF_DATE”, or “EXPIRED”.
Thereby transactions accessing the shared object can better interpret
the shared memory contents and prepare themselves for corresponding
clean-up procedures. |
New ABAP Tools
SAP Web AS 6.40 offers new tools and features to enhance developers’
productivity and adapt to the new ways ABAP applications are being used.
Memory Inspector
Traditionally, a typical ABAP program was executed as a short transaction,
so a detailed analysis of memory consumption wasn’t necessary. But
now, with long-running transactions in applications like customer interaction
centers, the Memory Inspector helps to analyze memory consumption in your
application over time. Simply switch on memory-consumption tracing by
entering the OK-code /hmusa, then use the same code to switch
off the tracing later.
The S_MEMORY_INSPECTOR transaction lets you examine the trace results
providing detailed information on allocated internal tables, strings,
objects, and anonymous data objects (see Figure 3). For
instance, suppose you want to access parts of your application to make
changes to a development object. Using Memory Inspector you take a look
and find 263 classes that have been loaded, and inside those programs
and classes are 939 table bodies. There are also 3,166 strings —
which is rather high — so that’s memory you’ll want
to inspect in more detail. Perhaps you’re using too many tables
inside your program, or wasting space inside the tables. You can even
inspect each individual table, or look at a class, class pool, names of
strings, and so on.
 |
Figure
3 |
Memory Inspector |
New Design for the Debugger
In SAP Web AS 6.40, the new design of ABAP Debugger cleanly separates
it from any program you are debugging. By separating the control of the
Debugger from your other applications, you can ensure that the results
of the Debugger program do not interact with the program you’re
checking. However, note that this separation leads to a slightly lower
performance, since the new Debugger runs in its own main mode.
Activatable Assertions and Breakpoints
Closely related to the new Debugger are new assertions and activatable
breakpoints. Assertions are logical conditions inserted into
the code that should, from a design-time perspective, always be true.
A classic example: when executing a POP operation, the stack should not
be empty. With ASSERT statements, if the condition is not met during execution,
the program is automatically stopped to analyze its current state.
A new feature also allows you to group breakpoints or assertions under
a particular ID, as in the ASSERT example in Figure 4.
This grouping is especially helpful in a support situation where you must
activate a set of breakpoints that stops program execution at critical
points in an application — now they can all be identified by the
same breakpoint ID. To define activatable breakpoints or assertions, use
transaction SAAB.
METHOD sort_by_name.
* sort algorithm
ASSERT ID test_sorted
CONDITION itab->is_sorted_by_name( ) <> ' '.
ENDMETHOD.
|
Figure
4 |
ASSERT Statement |
Conclusion
Over the past few decades, ABAP has proven itself as a programming language,
with a powerful set of development tools and a high level of maturity
when it comes to enterprise-level applications.
But as with all things, even with an established track record there’s
always room for enhancements. SAP’s commitment to continuing improvements
to the ABAP stack is ongoing. And while advances in the Workbench and
to the ABAP development platform have always been designed for greater
productivity and convenience for developers, these capabilities also now
offer unprecedented possibilities for your applications — whether
they’re designed for the SAP GUI, portals, Web, or third-party applications.
For more information on SAP Web AS 6.40 for ABAP development, see http://service.sap.com/netweaver.
1 Memory area of a fixed (configurable) size that stores the
session context.
2 Other examples are the metadata repositories in SAP BW and
the Workflow Engine, to name a few.
Karl Kessler joined SAP in 1992. He is the
Product Manager of the SAP NetWeaver foundation
including SAP Web Application Server, Web Dynpro,
ABAP Workbench and SAP NetWeaver Developer
Studio, and is responsible for all rollout
activities. You can reach him via email at karl.kessler@sap.com. |