ABAP Shared Objects

Session ID: ABAP251
ABAP Shared Objects

Shared Memory Programming Made Easy
Rolf Hammer, SAP AG
Holger Janz, SAP AG

Learning Objectives
As a result of this workshop, you will

be able to:
Understand the concepts of ABAP Shared Objects
Decide when (not) to use ABAP Shared Objects
Define shared memory areas
Store data in shared memory areas
Access data in shared memory areas
Adapt shared memory areas for your needs
Monitor shared memory areas
© SAP AG 2004, SAP TechEd / ABAP251 / 3

Motivation
Basic Concepts
Advanced Features 1
Advanced Features 2
What is Shared Memory ?
Data Access without Buffering
Data Access with Buffering by Copy
Data Access with in Place Buffering
Benefits for Application Programming
Different kinds of main memory on an application server

Session Memory
Bound to a single user session
Cannot be accessed by a different user session
Guarantees user isolation
Shared Memory (SHM)
Shared across session boundaries
No user isolation
Requires access control in a business application context
Application development has longed for buffering data in

shared memory for a long time

DB
User X
Session

Common data
retrieved from DB and
DB aggregated
User X
Session

Common data
retrieved from DB and
DB aggregated for
each user session
Common Common Common

Data Data Data
User X User Y User Z

Session Session Session

DB
User X
Session

Common data
retrieved from DB
DB
Common
Data
User X
Session

Common data
retrieved from DB,
DB aggregated
User X
Session

Shared Memory (SHM) Common data

Common retrieved from DB,
Data aggregated,
DB
copied (EXPORT) to SHM
Common
Data
User X
Session


Common retrieved from DB,
Data aggregated,
DB
copied (EXPORT) to SHM,
and copied (IMPORT) to
each user session
Common Common Common

Data Data Data



Common retrieved from DB
Data directly into SHM
DB
User X
Session


Data directly into SHM,
DB
aggregated in place
User X
Session


Data directly into SHM,
DB
aggregated in place
accessed copy-free by
other user sessions


Significant boost in overall performance due to

Reduced memory consumption
Data is kept only once in memory
Reduced runtime costs
Data is aggregated only once
Fast access at main memory speed
In place aggregation for “arbitrary” data
structures including strings, internal tables,
and references
Reduced maintenance costs due to

Simplified programming model in contrast to
solutions based on IMPORT / EXPORT

Applications Using Shared Objects
Workbench navigation
Data is aggregated only once
Ported to ABAP Shared Objects
Saves 3 MB session memory per user
About 100 times faster at first access
Master Data Framework (Financials Basis)

Speed up factor 1000 and more for where used queries
Memory costs reduced to 1/15 per session
Simplified code simplifies maintenance

Motivation
Basic Concepts
Advanced Features 1
Advanced Features 2
Usage Scenarios
Areas and Area Instances
Locking Concept
Creating and Accessing Contents
Usage Scenarios
Main usage scenarios

Shared buffers
Low update frequency (e.g. once a day to once per hour)
(Very) costly amount of data
Many parallel readers, single writer
Exclusive buffers
Access by a single writer or reader
Buffer content is kept across transactions
Coarse granular locking concept

Only a complete buffer can be locked
Rare updates
Readers and writers know each other

Usage Scenarios
Locking Concept
Shared object memory Shared Memory

Part of the shared memory Shared Object Memory
Customizable by profile parameter
Area Area
Shared object areas
I
Organizational units (type) n I
s I n
Defined at design time t n s
a s t
Identified by unique name n t a
c a n
e n c
Shared object area instances c e
e
Content stored at runtime
Unique name within the area
Single-instance area addressed by
default name

Area Instances and Objects
Objects are reachable via Instance

references
Root
Area instances have a root
object
All objects must be reachable
from the root object
Area instances are self-
contained, i.e. no outgoing
references to
User session memory
Other shared objects
area instances
Inner references are allowed

Design Time Support
Areas are defined at design time Area: cl_my_area

with the shared objects area
manager (transaction SHMA)
Instance
Area name corresponds to a
class to be generated Root: cl_my_root
(e.g. cl_my_area)
Name of root class must be
specified (e.g. cl_my_root)

Shared Memory Enabling of a Root Class
Common class
defined with class
builder (transaction
SE24)
Checkbox
‘Shared Memory
Enabled’ active

Definition of a Shared Memory Area
Special class
defined with the
shared objects area
manager
(transaction SHMA)
Root class must be

specified

Abstract Area Class
Transaction SHMA generates for each area a class

which inherits from the abstract class cl_shm_area
cl_shm_area
cl_my_area1 cl_my_area2 cl_my_area3

Usage Scenarios
Locking Concept
Locking Concept
Coarse granular locking concept

Lock kinds: read, write, and update
Only complete area instances can be locked
Write/Update locks are exclusive
In general immediate response to locking requests
(success or exception)
Only one read lock per internal session on the same
area instance
Default lock duration until end of current internal
session

Attaching to an Area Instance
Provides access to a shared

Instance
objects area instance
Root
Creates handle object
Sets appropriate lock
Makes reference to root

object available Handle
Handle Handle
Methods
attach_for_read User X User Y
Session Session
attach_for_write
attach_for_update

Example: Write Access
data:
... Open default
myShmHandle type ref to cl_my_area, instance for
myRoot type ref to cl_my_root. write
myShmHandle = cl_my_area=>attach_for_write( ).

Detaching from an Area Instance
Cancels access to a shared

objects area instance Instance
Invalidates handle object Root
Releases lock
Makes reference to root
object unavailable
Handle
Changes must be committed Handle Handle
or rolled back
User X User Y
Methods Session Session
detach
detach_commit
detach_rollback
Example: Detach from Write Access
data:
...
myShmHandle type ref to cl_my_area,
myRoot type ref to cl_my_root.
...
if ...
myShmHandle->detach_commit( ). Commit changes
else.
myShmHandle->detach_rollback( ). Rollback changes
endif.

Usage Scenarios
Locking Concept
Creating Data Objects
CREATE OBJECT … AREA HANDLE hdl.

Creates instance of a class
Only instance attributes are created
Class attributes exist only once per session
Class must be ‘shared memory enabled’
Class builder property flag
special addition SHARED MEMORY ENABLED
at class definition section
CREATE DATA … AREA HANDLE hdl.

Creates instance of a data type
All data types can be instantiated (future release)

Example: Filling Contents
data:
...
myShmHandle type ref to cl_my_area,
myRoot type ref to cl_my_root.
create object myRoot area handle myShmHandle.

myRoot->name = 'My first area instance'.
append wa to myRoot->itab. Create arbitrary (data)
... objects in shared memory
if ...
myShmHandle->set_root( myRoot ). Set root object and
myShmHandle->detach_commit( ). commit changes
else.
myShmHandle->detach_rollback( ).
endif.

Accessing Data Objects
All objects are accessible via root object
Handle provides reference to root object
Example:
x = myShmHandle->root->myObject->myAttribute.

Example: Accessing Contents
data:
Open default
myShmHandle type ref to cl_my_area.
instance
for read
myShmHandle = cl_my_area=>attach_for_read( ).
read table myShmHandle->root->itab Access root

into wa index i. object
components
...
myShmHandle->detach( ).
Release lock

Shared Objects Area Monitor
Shared objects area

monitor (transaction
SHMM)
Overview on areas,
instances, and
locks
Content browser

Demo
Demo 1

Exercise
Exercise 1

Basic Concepts
Advanced Features 1
Advanced Features 2
Multi Attach
Preloading
Versioning
Client Dependency
Multi Attach
Method MULTI_ATTACH must be used to attach to more than one

area within one internal session
Precluding of dead lock situations
How to use MULTI_ATTACH

Pass an internal table with all needed area description
Specify ignoring errors, if needed
Specify wait time, if needed
Handles for every attached area or exception object will be

returned

Multi Attach Example
data:
attach_tab type shm_attach_tab,
attach_wa like line of attach_tab,
error_flag type abap_bool.
attach_wa-area_name = 'ZCL_MY_AREA_1'.
attach_wa-inst_name = cl_shm_area=>default_instance.
attach_wa-lock_kind = cl_shm_area=>lock_kind_read.
insert attach_wa into table attach_tab.
attach_wa-area_name = 'ZCL_MY_AREA_2'.
attach_wa-inst_name = cl_shm_area=>default_instance.
attach_wa-lock_kind = cl_shm_area=>lock_kind_write.
insert attach_wa into table attach_tab.
cl_shm_area=>multi_attach(
importing error_flag = error_flag
changing attach_tab = attach_tab ).

Multi Attach
Preloading
Versioning
Client Dependency
Preloading
Automatic preloading (buffer warm-up) for area instances can

be specified at design time
Requires the specification of a loader class implementing the
interface if_shm_build_instance
The automatically started loader runs asynchronously in a

separate session (of the same user) to avoid side effects on the
caller
Possible options for the preload starting point

Due to a read request if no active version is available
Due to invalidation, i.e. if the active version becomes
out of date or expires (includes above case)

Preloading
Preloading is
specified at design
time using
transaction SHMA

Preloading Example
data:
hdl type ref to zcl_my_area,
excp type ref to cx_shm_no_active_version.
try.
hdl = zcl_my_area=>attach_for_read( ).
catch cx_shm_no_active_version into excp.
if excp->textid <>
cx_shm_no_active_version=>build_started and
excp->textid <>
cx_shm_no_active_version=>build_not_finished.
raise exception excp.
endif.
wait up to 1 seconds.
hdl = zcl_my_area=>attach_for_read( ).
endtry.

Multi Attach
Preloading
Versioning
Client Dependency
Versioning Example
Instance
Version: active
Reader1

Versioning Example
Instance
Version: active Version: under

construction
Reader1
Writer

Versioning Example
Instance
Version: active Version: under

construction
Reader1
Reader2 Writer

Versioning Example
Instance
Version: Version: active

out of date
Reader1
Reader2
Versioning Example
Instance

out of date
Reader1
Reader2 Reader3

Versioning Example
Instance

out of date
Reader1
Reader3

Versioning Example
Instance

expired
Reader3

Versioning Example
Instance
Version: active
Reader3

States of Versions
The 4 States
1. Under construction (0..1): As long as a version is being changed
2. Active (0..1): Last committed version used for further read attaches
3. Out of date (0..n): Version with still attached readers, no further read
attaches possible
4. Expired (0..n): Out of date and no more readers; will be automatically
garbage collected
Version Version Version Version
under active out of date expired

construction

Versioning Concept
Versioning is defined at design time
Maximum number of versions can be specified

at design time
Versioning guarantees that read attaches can be satisfied

in general
Strictly speaking a version is an area instance version

Versioning
Versioning is
specified at design
time using
transaction SHMA

Multi Attach
Preloading
Versioning
Client Dependency
Client Dependency
Client dependency is specified at design time

Needed if area instances shall be client aware,
i.e. if different clients require different instances
Analogy to database client handling

Client is part of the area instance name
Optional client parameter for most area methods
(default: current client, only possible without preloading)
Predefined constant to address all clients

Client Dependency
Client dependency
is specified at
design time using
transaction SHMA

Demo
Demo 2

Exercise
Exercise 2

Basic concepts
Advanced Features 1
Advanced Features 2
Transactional Areas and Propagation
Displacement
Memory Limits
Binding
Transactional Areas Motivation
Database changes
Area
Instance
Version
1
Database

Database changes
Area
Area instance depending on
database changes Instance
Version
1
Version
2
Database

Database changes
Area
Area commit, version 1 gets
out of date Version
1
Version
2
Database

Database changes
Area
out of date and expires
Version
2
Database

Database changes
Area
out of date and expires
Database rollback Î Version

inconsistency in area instance 2
???
Database

Transactional Areas Solution
Transactional behavior is specified at design time

Versions finished with detach_commit becomes active
with the next database commit
Read attaches before the next database commit will be
routed to still active version
Example: Area with versioning
v1 active v1 active v1 out of date

v2 under construction v2 pending v2 active
read v1
read v1
Read v2
write v2
detach_commit DB commit
Propagation Motivation
Instances reside on Application Server

instances
Database
AppServer 1 AppServer 2 AppServer 3
Instance Instance Instance

Version 1 Version 1 Version 1


instances
Instance changes
Database

Version 2


instances
Instance changes do not affect other servers
Database

Version 2


instances
Instance changes do not affect other servers
Instance mismatch on other application servers

Database

Version 1 Version 1
Version 2 ??? ???

Propagation Solution
Instance changes are not propagated to other

servers, only an invalidation record is sent
Database

Version 1 Version
version1 1 Version
version1 1
??? ???
Version 2

Propagation Solution
Instance changes are not propagated to other

servers, only an invalidation record is sent
New versions are created at next read request

via automatic preloading
Database

Version 1 Version 1

Propagation
Propagation is automatically specified at design time for all

transactional areas
Needed for area instances that shall be kept in sync
on several application servers
Propagation is only possible for transactional areas

Technical reason: sync records via database
Conceptual reason: In general propagation will be
needed, if area contents depend on database contents
Pull model
Receiving a sync record lets the active version become
out of date
Rebuild is not forced (push model) but depends on
preloading options
Propagation only means a system wide invalidation of areas.

Automatic preloading is used to create updated version.
Transactional Areas
are specified at
design time using
transaction SHMA
Propagation is done
via invalidation
using the
PROPAGATE
methods

Transactional Areas and Propagation Example
data:
root type ref to zcl_my_area_root,
hdl type ref to zcl_my_area.
hdl = zcl_my_area=>attach_for_write( ).
create object root area handle hdl.
hdl->set_root( root ).
hdl->detach_commit( ).
zcl_my_area=>propagate_instance( ).
commit work.

Displacement
Memory Limits
Binding
Displacement
Displacement means that an area instance version with no

active readers can be pushed out of shared memory
Dynamic area property specified at design time
Recommended on 32-bit systems only
The following displacement modes can be specified

Simple displacement without saving area contents
Displacement by serialization to disk (future SAP NetWeaver
release)
Every object must be serializable (tag
interface if_serializable_object)
Deserialization at the next read request

Displacement
Displacement is
specified at design
time using
transaction SHMA

Displacement
Memory Limits
Binding
Lifetime
Memory Limits
Memory limits are defined at design time for

one area instance
all instances of one area (future SAP NetWeaver release)
Used to prevent applications to run wild in shared memory.
Gives tools and administrator an idea how much shared

memory is needed for a certain application.

Memory Limits
Memory Limits is
specified at design
time using
transaction SHMA

Displacement
Memory Limits
Lifetime
Lifetime
Lifetime is defined at design time
Automatic invalidation or preloading after lifetime
One out of three kinds of lifetime can be specified

Up to expiry (invalidation time), invalidation
Up to update (refresh time), preloading
Without read access (idle time), invalidation
Used to free unused or to refresh to contents of shared

memory

Lifetime
Lifetime is specified
at design time using
transaction SHMA

Demo
Demo 3

Exercise
Exercise 3

Encapsulation
Avoid direct access to shared memory area instances
Session Area
Reader
Instance1
Reader
Instance2
Reader
Instance3
Writer

Broker
Instead, it is recommended to communicate with an area

via a broker class that encapsulates
Area initialization
Area access
Lock administration
Authority checks
Session Area
Reader
Instance1
Reader
Instance2
Broker
Reader
Instance3
Reader

Area Properties - Overview
The following properties can be specified at design time

Versioning
Preloading
Transactional
Propagation
Client dependency
Displacement
Memory limits
Lifetime

Additional Features
Conceptual
Error handling via exceptions
Query methods for handle state
Special roll handle to address roll area
Technical
Consistency check for types used at area
build-up and attach time
Garbage collection for area instances
Copy-on-write becomes copy-on-detach for
internal tables and strings

Summary
ABAP Shared Objects is used to share common data

between different session
Coarse granular locking concept supports shared buffer

or exclusive buffer
Versioning is used to implement high available services
Transactional areas are used to synchronize shared

object instances with database
Propagation is used to synchronize shared object

instances on different application server

Further Information
Î Public Web:
www.sap.com
SAP Developer Network: www.sdn.sap.com
SAP Customer Services Network: www.sap.com/services/
Î Related SAP Education Training Opportunities

http://www.sap.com/education/
Î Related Workshops/Lectures at SAP TechEd 2004

ABAP201, Best of ABAP - The Ultimate ABAP 6.40 Feature Show , 2h Lect.
ABAP351, Advanced and Generic Programming in ABAP, 4h Hands-on
ABAP253, ABAP Troubleshooting, 4h Hands-on
ABAP151, ABAP Objects for Java Developers, 2h Hands-on
ABAP255, New ABAP Debugger and Memory Inspector , 2h Hands-on

SAP Developer Network
Look for SAP TechEd ’04 presentations and videos on

the SAP Developer Network.
Coming in December.
http://www.sdn.sap.com/

Questions?
Q&A

Feedback
Please complete your session evaluation.
Be courteous — deposit your trash,

and do not take the handouts for the following session.
Thank You !

Copyright 2004 SAP AG. All Rights Reserved
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express
permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other
software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries,
pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or
registered trademarks of IBM Corporation in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered
trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium,
Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and
implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein
as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other
countries all over the world. All other product and service names mentioned are the trademarks of their respective
companies. Data contained in this document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated
companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group
shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and
services are those that are set forth in the express warranty statements accompanying such products and services, if any.
Nothing herein should be construed as constituting an additional warranty.

ABAP Shared Objects - Shared Memory Programming Made Easy

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ABAP Shared Objects - Shared Memory Programming Made Easy

Uploaded by

Copyright:

Available Formats

Session ID: ABAP251

Holger Janz, SAP AG

As a result of this workshop, you will

© SAP AG 2004, SAP TechEd / ABAP251 / 3

Different kinds of main memory on an application server

Application development has longed for buffering data in

© SAP AG 2004, SAP TechEd / ABAP251 / 6

© SAP AG 2004, SAP TechEd / ABAP251 / 8

© SAP AG 2004, SAP TechEd / ABAP251 / 9

Common Common Common

User X User Y User Z

© SAP AG 2004, SAP TechEd / ABAP251 / 10

© SAP AG 2004, SAP TechEd / ABAP251 / 12

© SAP AG 2004, SAP TechEd / ABAP251 / 13

© SAP AG 2004, SAP TechEd / ABAP251 / 14

Shared Memory (SHM) Common data

© SAP AG 2004, SAP TechEd / ABAP251 / 15

Shared Memory (SHM) Common data

Common Common Common

User X User Y User Z

© SAP AG 2004, SAP TechEd / ABAP251 / 16

Shared Memory (SHM) Common data

© SAP AG 2004, SAP TechEd / ABAP251 / 18

Shared Memory (SHM) Common data

© SAP AG 2004, SAP TechEd / ABAP251 / 19

Shared Memory (SHM) Common data

User X User Y User Z

© SAP AG 2004, SAP TechEd / ABAP251 / 20

Significant boost in overall performance due to

Reduced maintenance costs due to

© SAP AG 2004, SAP TechEd / ABAP251 / 22

Master Data Framework (Financials Basis)

© SAP AG 2004, SAP TechEd / ABAP251 / 23

Main usage scenarios

Coarse granular locking concept

© SAP AG 2004, SAP TechEd / ABAP251 / 26

Shared object memory Shared Memory

© SAP AG 2004, SAP TechEd / ABAP251 / 28

 Objects are reachable via Instance

© SAP AG 2004, SAP TechEd / ABAP251 / 29

Areas are defined at design time Area: cl_my_area

© SAP AG 2004, SAP TechEd / ABAP251 / 30

© SAP AG 2004, SAP TechEd / ABAP251 / 31

Root class must be

© SAP AG 2004, SAP TechEd / ABAP251 / 32

Transaction SHMA generates for each area a class

cl_my_area1 cl_my_area2 cl_my_area3

© SAP AG 2004, SAP TechEd / ABAP251 / 33

Coarse granular locking concept

© SAP AG 2004, SAP TechEd / ABAP251 / 35

Provides access to a shared

 Sets appropriate lock

 Makes reference to root

© SAP AG 2004, SAP TechEd / ABAP251 / 36

© SAP AG 2004, SAP TechEd / ABAP251 / 37

Cancels access to a shared

 Invalidates handle object Root

© SAP AG 2004, SAP TechEd / ABAP251 / 39

CREATE OBJECT … AREA HANDLE hdl.

CREATE DATA … AREA HANDLE hdl.

© SAP AG 2004, SAP TechEd / ABAP251 / 41

create object myRoot area handle myShmHandle.

Objects are reachable via Instance

Sets appropriate lock

Makes reference to root

Invalidates handle object Root

Method MULTI_ATTACH must be used to attach to more than one

Precluding of dead lock situations

Specify ignoring errors, if needed

Specify wait time, if needed

Handles for every attached area or exception object will be

The automatically started loader runs asynchronously in a

Possible options for the preload starting point

Versioning is defined at design time

Maximum number of versions can be specified

Versioning guarantees that read attaches can be satisfied

Strictly speaking a version is an area instance version