Excerpted from the book 'Next Generation ABAP Development', Authors Rich Heilman and Thomas Jung, ISBN 1592291392...
Copyright 2007. Written permission from SAP PRESS is required for all other uses. Copyright © 2007 SAP PRESS America. All rights reserved. Email: email@example.com. SAP PRESS America, 11300 Rockville Pike, Suite 1100, Rockville, MD 20852-3030, USA.
Download chapter 5: 'Shared Memory Objects'
Shared Memory Objects
Shared memory objects are ABAP Object Instances, which can be stored in the shared memory area on an application server. Instead of going to the database to retrieve the required data, the data is accessed through the shared memory, thereby providing faster data retrieval.
This shared memory area can be accessed by all of the ABAP programs running on that application server. Before the upgrade to SAP ERP 6.0, Russel used the
EXPORT/IMPORT statements with the
SHARED BUFFER or
SHARED MEMORY extensions to access a similar memory buffer area. So what are the advantages of using this new functionality?
- First, it is read access to shared memory without the need to copy it into user session memory. Technically, an application does a remote attach to the memory segment within shared memory and directly interacts with it.
- Secondly, the new shared memory technique is implemented through ABAP Objects; therefore, you are provided with robust tools to interact with shared memory through code. Ultimately, you aren't just buffering raw sets of data; you're also providing a shared mechanism to access the business logic wrapped around this data.
- There are also dedicated tools for the monitoring and administration of these shared areas and the objects within them. Transaction SHMM, for example, provides tools to monitor the size and number of objects within a shared area, as well as enabling administrators to force objects out of memory if necessary.
5.1 Getting Started
Russel has spent a considerable amount of time developing the database access layer for this project and wants to ensure that performance is at an optimal level. He decides to leverage the shared memory objects functionality to increase performance when accessing some of the data in the database.
To use this feature of the ABAP runtime environment, Russel will have to create several new types of objects. Shared memory objects are implemented in two parts — the shared object root and area classes.
- The root class is the definition of the object that will be stored in shared memory. An instance (or multiple instances) of this class will reside in shared memory. Therefore this class's attributes should represent the data that you want cached and the methods of the class are the way that you access this data.
- The shared memory area class, on the other hand, will be a generated class. It abstracts a section of shared memory that is set aside for one or more instances of a particular root class. The methods of this area class provide the tools to attach to the shared memory area in order to read or manipulate it. The sole purpose of the area class is to return instances of the root class.
5.1.1 Area Root Class Creation
Russel decides that the
ZCS_COURSE table would be a good candidate to create a shared memory object. Shared memory objects should primarily be used for objects that are read often, but updated infrequently. This is due to the locking mechanism that is used by shared objects. Although having multiple read locks across separate user sessions is possible and is the norm, any form of change lock is exclusive (i.e., it doesn't even allow parallel read locks on the same area instance).
This does make
ZCS_COURSE a good fit. New courses are rarely created or changed during the school year. All updates are done all at once, before planning for the next semester begins. Technically, this means that this table will have frequent read accesses by students and teachers concurrently, but the data will rarely change.
Russel's first step in implementing a shared memory object to represent
ZCS_ COURSE is to create the area root class. This class implements the setter and getter methods, which are used to access the data to be stored in the shared memory area. It could also include business logic that further manipulates the data during access operations. For instance, it might include calculations, the results of which could also be stored in shared memory. This is where the value of the shared memory object can extend well beyond the scope of just the buffering of data stored within the database.
Russel creates the class
ZCL_CS_COURSE_SHMO_ROOT and assigns it to the
ZCS_ DDIC package using transaction code SE80 (see Figure 5.1).
Russel then sets the Shared Memory-Enabled checkbox on the Properties tab (see Figure 5.2). This tells the system that the class is eligible to be used as a root class for a shared memory object.
The idea of using shared memory objects is to store data in memory, which can be used at runtime. Therefore, Russel needs to add an attribute to this class that will hold the data retrieved from the
ZCS_COURSE database table.
Although it is technically possible to create public attributes of the root class that can be accessed directly from an instance of the class, Russel wants to follow good object-oriented designs and encapsulate all of his attribute accesses within methods. This gives him more control in case he wants to embed other operations within an access to this attribute. Therefore he defines the attribute as a Private Instance attribute.
Visit the SAP Press website for a detailed description and to learn how to purchase this title.