ABAP Shared Objects

(1)

Session ID: ABAP251

(2)

Rolf Hammer, SAP AG

Holger Janz, SAP AG

(3)

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

(4)

Advanced Features 1

Motivation

Basic Concepts

(5)

What is Shared Memory ?

Data Access without Buffering

Data Access with Buffering by Copy Data Access with in Place Buffering Benefits for Application Programming

(6)

What is Shared Memory ?

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

(7)

Data Access with Buffering by Copy Data Access with in Place Buffering Benefits for Application Programming

(8)

Data Access without Buffering

User X Session DB

(9)

Data Access without Buffering

Common data

retrieved from DB and

(10)

Data Access without Buffering

User Y Session Common Data User X Session Common Data DB

Common data

retrieved from DB and

aggregated for

each user session

User Z Session Common Data Common Data Common Data

(11)

Data Access with Buffering by Copy

Data Access with in Place Buffering Benefits for Application Programming

(12)

Data Access with Buffering by Copy

(13)

Data Access with Buffering by Copy

User X Session Common Data DB

Common data

retrieved from DB

(14)

Data Access with Buffering by Copy

Common data

retrieved from DB, aggregated

(15)

Data Access with Buffering by Copy

Common data

retrieved from DB, aggregated, copied (EXPORT) to SHM Shared Memory (SHM) Common Data

(16)

Data Access with Buffering by Copy

Common data

retrieved from DB, aggregated, copied (EXPORT) to SHM,

and copied (IMPORT) to each user session

Shared Memory (SHM) Common Data User Y Session Common Data User Z Session Common Data

(17)

Data Access with Buffering by Copy

Data Access with in Place Buffering

(18)

Data Access with in Place Buffering

Common data

retrieved from DB directly into SHM Shared Memory (SHM) Common Data

(19)

Data Access with in Place Buffering

DB

Common data

retrieved from DB directly into SHM, aggregated in place Shared Memory (SHM) Common Data User X Session

(20)

Data Access with in Place Buffering

Common data

retrieved from DB directly into SHM, aggregated in place accessed copy-free by other user sessions Shared Memory (SHM) Common Data User Y Session User Z Session

(21)

Data Access with Buffering by Copy Data Access with in Place Buffering

(22)

Benefits for Application Programming

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

(23)

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

(24)

Advanced Features 1

Motivation

Basic Concepts

(25)

Usage Scenarios

Areas and Area Instances Locking Concept

(26)

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

(27)

Usage Scenarios

Areas and Area Instances

Locking Concept

(28)

Areas and Area Instances

Shared object memory

Part of the shared memory

Customizable by profile parameter

Shared object areas

Organizational units (type)

Defined at design time

Identified by unique name

Shared object area instances

Content stored at runtime

Unique name within the area

Single-instance area addressed by default name Shared Memory Area Area I n s t a n c e I n s t a n c e I n s t a n c e

(29)

Area Instances and Objects

Objects are reachable via references

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

Instance

(30)

Design Time Support

Instance

Area: cl_cl_mmy_areay_area

Root: cl_my_rootcl_my_root

Areas are defined at design time

with the shared objects area

manager (transaction SHMA)

Area name corresponds to a

class to be generated

(e.g. cl_my_area)

Name of root class must be specified (e.g. cl_my_root)

(31)

Shared Memory Enabling of a Root Class

Common class defined with class builder (transaction SE24)

Checkbox

‘Shared Memory Enabled’ active

(32)

Definition of a Shared Memory Area

Special class defined with the shared objects area manager

(transaction SHMA) Root class must be specified

(33)

Abstract Area Class

Transaction SHMA generates for each area a class

which inherits from the abstract class

cl_shm_area

cl_shm_area

(34)

Usage Scenarios

Areas and Area Instances

Locking Concept

(35)

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

(36)

Attaching to an Area Instance

Instance Root User Y Session Handle User X Session Handle Handle

Provides access to a shared

objects area instance

Creates handle

object

Sets

appropriate

lock

Makes reference to

root

object

available

Methods

attach_for_read

attach_for_write

attach_for_update

(37)

data: ...

myShmHandle type ref to cl_my_area,

myRoot type ref to cl_my_root.

myShmHandle = cl_my_area=>attach_for_write( ).

Open default instance for write

(38)

Detaching from an Area Instance

Instance Root User Y Session Handle User X Session Handle Handle

Cancels access to a shared

objects area instance

Invalidates handle

object

Releases lock

Makes reference to

root

object unavailable

Changes must be committed

or rolled back

Methods

detach

(39)

data: ...

myShmHandle type ref to cl_my_area,

myRoot type ref to cl_my_root.

myShmHandle = cl_my_area=>attach_for_write( ). ... if ... myShmHandle->detach_commit( ). else. myShmHandle->detach_rollback( ). endif.

Example: Detach from Write Access

Rollback changes Commit changes

(40)

Usage Scenarios

Areas and Area Instances Locking Concept

(41)

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

(42)

data: ...

myShmHandle type ref to cl_my_area,

myRoot type ref to cl_my_root.

myShmHandle = cl_my_area=>attach_for_write( ). create object myRoot area handle myShmHandle. myRoot->name = 'My first area instance'.

append wa to myRoot->itab. ...

if ...

myShmHandle->set_root( myRoot ). myShmHandle->detach_commit( ). else.

myShmHandle->detach_rollback( ). endif.

Example: Filling Contents

Create arbitrary (data)

objects in shared memory Set root object and commit changes

(43)

Accessing Data Objects

All objects are accessible

via root object

Handle

provides reference to root object

Example:

(44)

data:

myShmHandle type ref to cl_my_area.

myShmHandle = cl_my_area=>attach_for_read( ).

read table myShmHandle->root->itab

into wa index i. ... myShmHandle->detach( ). Open default instance for read

Example: Accessing Contents

Access root object

components

(45)

Shared Objects Area Monitor

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

(46)

Demo

(47)

Exercise

(48)

Advanced Features 2

Basic Concepts

(49)

Multi Attach

Preloading Versioning

(50)

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

(51)

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 ).

(52)

Multi Attach

Preloading

Versioning

(53)

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)

(54)

Preloading

Preloading is

specified at design time using

(55)

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.

(56)

Multi Attach Preloading

Versioning

(57)

Versioning Example

Instance

Version: active

(58)

Versioning Example

Instance

Version: active Version: under

construction

(59)

Versioning Example

Instance

Version: active Version: under

construction

Writer Reader1

(60)

Versioning Example

Instance Version: out of date Version: active Reader1

(61)

Versioning Example

Instance Version: out of date Version: active Reader1 Reader2 Reader3

(62)

Versioning Example

Instance Version: out of date Version: active Reader1

(63)

Versioning Example

Instance Version: expired Version: active Reader3

(64)

Versioning Example

Instance

(65)

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 under construction Version active Version out of date Version expired

(66)

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

(67)

Versioning

Versioning is specified at design time using transaction SHMA

(68)

Multi Attach Preloading Versioning

(69)

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)

(70)

Client Dependency

Client dependency is specified at

design time using transaction SHMA

(71)

Demo

(72)

Exercise

(73)

Advanced Features 2

Basic concepts

(74)

Transactional Areas and Propagation

Displacement Memory Limits Binding

(75)

Transactional Areas Motivation

Instance Area Database Version 1 Database changes

(76)

Transactional Areas Motivation

Database

Database changes

Area instance depending on

database changes _Instance

Area

Version 1

Version 2

(77)

Transactional Areas Motivation

Database

Area instance depending on database changes

Area commit, version 1 gets out of date Instance Area Version 1 Version 2

(78)

Transactional Areas Motivation

Database

Area commit, version 1 gets out of date and expires

Instance Area

Version 2

(79)

Transactional Areas Motivation

Database

Area commit, version 1 gets out of date and expires

Database rollback Î

inconsistency in area instance

Instance Area

Version 2 ???

(80)

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 v2 under construction v1 out of date v2 active v1 active v2 pending Read v2 read v1 read v1 write v2

(81)

Propagation Motivation

Database Instances reside on Application Server

instances Instance AppServer 1 Version 1 Instance AppServer 2 Version 1 Instance AppServer 3 Version 1

(82)

Propagation Motivation

Database

Instances reside on Application Server instances Instance changes Instance AppServer 1 Version 1 Version 2 Instance AppServer 2 Version 1 Instance AppServer 3 Version 1

(83)

Propagation Motivation

Database

Instances reside on Application Server instances

Instance changes do not affect other servers

Instance AppServer 1 Version 1 Version 2 Instance AppServer 2 Version 1 Instance AppServer 3 Version 1

(84)

Propagation Motivation

Database

Instances reside on Application Server instances

Instance changes do not affect other servers

Instance mismatch on other application servers

Instance AppServer 1 Version 2 Instance AppServer 2 Version 1 ??? Instance AppServer 3 Version 1 ???

(85)

Propagation Solution

Database Instance changes are not propagated to other

servers, only an invalidation record is sent

Instance AppServer 1 Version 1 Version 2 Instance AppServer 2 version1 ??? Instance AppServer 3 version1 ??? Version 1 Version 1

(86)

Propagation Solution

Database

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

Instance AppServer 1 Version 2 Instance AppServer 2 Version 1 Version 2 Instance AppServer 3 Version 1 Version 2

(87)

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

.

(88)

Transactional Areas and Propagation

Transactional Areas are specified at

design time using transaction SHMA Propagation is done via invalidation using the PROPAGATE methods

(89)

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.

(90)

Transactional Areas and Propagation

Displacement

Memory Limits Binding

(91)

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)

(92)

Displacement

Displacement is specified at design time using

(93)

Transactional Areas and Propagation Displacement

Memory Limits

Binding Lifetime

(94)

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.

(95)

Memory Limits

Memory Limits is specified at design time using transaction SHMA

(96)

Lifetime

Transactional Areas and Propagation Displacement

(97)

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

(98)

Lifetime

Lifetime is specified at design time using transaction SHMA

(99)

Demo

(100)

Exercise

(101)

Encapsulation

Reader Reader Session Area Instance1 Instance2 Instance3 Reader Writer

(102)

Reader Reader Reader Reader Session

Broker

Area Instance1 Instance2 Instance3

Instead, it is recommended to communicate with an area

via a broker class that encapsulates

Broker

Area initialization Area access

Lock administration Authority checks

(103)

Area Properties - Overview

The following properties can be specified at design time

Versioning Preloading Transactional Propagation Client dependency Displacement Memory limits Lifetime

(104)

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

(105)

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

(106)

Further Information

Î Public Web:

www.sap.com

SAP Developer Network: www.sdn.sap.com

SAP Customer Services Network: www.sap.com/services/

Î 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

Î Related SAP Education Training Opportunities

(107)

SAP Developer Network

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

Coming in December.

(108)

Q&A

(109)

Please complete your session evaluation.

Be courteous — deposit your trash,

and do not take the handouts for the following session.

Feedback

(110)

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

ABAP Shared Objects - Shared Memory Programming Made Easy

Session ID: ABAP251

ABAP Shared Objects

Rolf Hammer, SAP AG

Holger Janz, SAP AG

Learning Objectives

As a result of this workshop, you will

be able to:

Advanced Features 1

Motivation

Basic Concepts

What is Shared Memory ?

Different kinds of main memory on an application server



Session Memory



Shared Memory (SHM)

Application development has longed for buffering data in

shared memory for a long time

Data Access without Buffering

Data Access without Buffering

Common data

Data Access without Buffering

Common data

Data Access with Buffering by Copy

Data Access with Buffering by Copy

Common data

Data Access with Buffering by Copy

Common data

Data Access with Buffering by Copy

Common data

Data Access with Buffering by Copy

Common data

Data Access with in Place Buffering

Common data

Data Access with in Place Buffering

Common data

Data Access with in Place Buffering

Common data

Benefits for Application Programming

Significant boost in overall performance due to



Reduced memory consumption



Reduced runtime costs

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

Advanced Features 1

Motivation

Basic Concepts

Usage Scenarios

Main usage scenarios



Shared buffers



Exclusive buffers

attach_for_read

attach_for_write

attach_for_update