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

© SAP AG 2004, SAP TechEd / ABAP251 / 6

What is Shared Memory ?
Data Access without Buffering
Data Access with Buffering by Copy
Data Access with in Place Buffering
Benefits for Application Programming
 Data Access without Buffering

DB

User X
Session

© SAP AG 2004, SAP TechEd / ABAP251 / 8

 Data Access without Buffering

Common data
„ retrieved from DB and
DB „ aggregated

User X
Session

© SAP AG 2004, SAP TechEd / ABAP251 / 9

 Data Access without Buffering

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

© SAP AG 2004, SAP TechEd / ABAP251 / 10

What is Shared Memory ?
Data Access without Buffering
Data Access with Buffering by Copy
Data Access with in Place Buffering
Benefits for Application Programming
 Data Access with Buffering by Copy

DB

User X
Session

© SAP AG 2004, SAP TechEd / ABAP251 / 12

 Data Access with Buffering by Copy

Common data
„ retrieved from DB
DB

Common
Data

User X
Session

© SAP AG 2004, SAP TechEd / ABAP251 / 13

 Data Access with Buffering by Copy

Common data
„ retrieved from DB,
DB „ aggregated

User X
Session

© SAP AG 2004, SAP TechEd / ABAP251 / 14

 Data Access with Buffering by Copy

Shared Memory (SHM) Common data

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

Common
Data

User X
Session

© SAP AG 2004, SAP TechEd / ABAP251 / 15

 Data Access with Buffering by Copy

Shared Memory (SHM) Common data

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

Common Common Common

Data Data Data

User X User Y User Z

Session Session Session

© SAP AG 2004, SAP TechEd / ABAP251 / 16

What is Shared Memory ?
Data Access without Buffering
Data Access with Buffering by Copy
Data Access with in Place Buffering
Benefits for Application Programming
 Data Access with in Place Buffering

Shared Memory (SHM) Common data

Common „ retrieved from DB
Data directly into SHM
DB

User X
Session

© SAP AG 2004, SAP TechEd / ABAP251 / 18

 Data Access with in Place Buffering

Shared Memory (SHM) Common data

Common „ retrieved from DB
Data directly into SHM,
DB
„ aggregated in place

User X
Session

© SAP AG 2004, SAP TechEd / ABAP251 / 19

 Data Access with in Place Buffering

Shared Memory (SHM) Common data

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

User X User Y User Z

Session Session Session

© SAP AG 2004, SAP TechEd / ABAP251 / 20

What is Shared Memory ?
Data Access without Buffering
Data Access with Buffering by Copy
Data Access with in Place Buffering
Benefits for Application Programming
 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

© SAP AG 2004, SAP TechEd / ABAP251 / 22

 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

© SAP AG 2004, SAP TechEd / ABAP251 / 23

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

© SAP AG 2004, SAP TechEd / ABAP251 / 26

Usage Scenarios
Areas and Area Instances
Locking Concept
Creating and Accessing Contents
 Areas and Area Instances

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

© SAP AG 2004, SAP TechEd / ABAP251 / 28

 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

© SAP AG 2004, SAP TechEd / ABAP251 / 29

 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)

© SAP AG 2004, SAP TechEd / ABAP251 / 30

 Shared Memory Enabling of a Root Class

Common class
defined with class
builder (transaction
SE24)

Checkbox
‘Shared Memory
Enabled’ active

© SAP AG 2004, SAP TechEd / ABAP251 / 31

 Definition of a Shared Memory Area

Special class
defined with the
shared objects area
manager
(transaction SHMA)

Root class must be

specified

© SAP AG 2004, SAP TechEd / ABAP251 / 32

 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

© SAP AG 2004, SAP TechEd / ABAP251 / 33

Usage Scenarios
Areas and Area Instances
Locking Concept
Creating and Accessing Contents
 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

© SAP AG 2004, SAP TechEd / ABAP251 / 35

 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

© SAP AG 2004, SAP TechEd / ABAP251 / 36

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

© SAP AG 2004, SAP TechEd / ABAP251 / 37

 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
© SAP AG 2004, SAP TechEd / ABAP251 / 38
 Example: Detach from Write Access

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( ). Commit changes
else.
myShmHandle->detach_rollback( ). Rollback changes
endif.

© SAP AG 2004, SAP TechEd / ABAP251 / 39

Usage Scenarios
Areas and Area Instances
Locking Concept
Creating and Accessing Contents
 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)

© SAP AG 2004, SAP TechEd / ABAP251 / 41

 Example: Filling Contents

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

© SAP AG 2004, SAP TechEd / ABAP251 / 42

 Accessing Data Objects

All objects are accessible via root object

Handle provides reference to root object

Example:
x = myShmHandle->root->myObject->myAttribute.

© SAP AG 2004, SAP TechEd / ABAP251 / 43

 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

© SAP AG 2004, SAP TechEd / ABAP251 / 44

 Shared Objects Area Monitor

Shared objects area

monitor (transaction
SHMM)

Overview on areas,
instances, and
locks

Content browser

© SAP AG 2004, SAP TechEd / ABAP251 / 45

 Demo

Demo 1

© SAP AG 2004, SAP TechEd / ABAP251 / 46

 Exercise

Exercise 1

© SAP AG 2004, SAP TechEd / ABAP251 / 47

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

© SAP AG 2004, SAP TechEd / ABAP251 / 50

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

© SAP AG 2004, SAP TechEd / ABAP251 / 51

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)

© SAP AG 2004, SAP TechEd / ABAP251 / 53

 Preloading

Preloading is
specified at design
time using
transaction SHMA

© SAP AG 2004, SAP TechEd / ABAP251 / 54

 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.

© SAP AG 2004, SAP TechEd / ABAP251 / 55

Multi Attach
Preloading
Versioning
Client Dependency
 Versioning Example

Instance

Version: active

Reader1

© SAP AG 2004, SAP TechEd / ABAP251 / 57

 Versioning Example

Instance

Version: active Version: under

construction

Reader1
Writer

© SAP AG 2004, SAP TechEd / ABAP251 / 58

 Versioning Example

Instance

Version: active Version: under

construction

Reader1
Reader2 Writer

© SAP AG 2004, SAP TechEd / ABAP251 / 59

 Versioning Example

Instance

Version: Version: active

out of date

Reader1
Reader2
© SAP AG 2004, SAP TechEd / ABAP251 / 60
 Versioning Example

Instance

Version: Version: active

out of date

Reader1
Reader2 Reader3

© SAP AG 2004, SAP TechEd / ABAP251 / 61

 Versioning Example

Instance

Version: Version: active

out of date

Reader1
Reader3

© SAP AG 2004, SAP TechEd / ABAP251 / 62

 Versioning Example

Instance

Version: Version: active

expired

Reader3

© SAP AG 2004, SAP TechEd / ABAP251 / 63

 Versioning Example

Instance

Version: active

Reader3

© SAP AG 2004, SAP TechEd / ABAP251 / 64

 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

© SAP AG 2004, SAP TechEd / ABAP251 / 65

 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

© SAP AG 2004, SAP TechEd / ABAP251 / 66

 Versioning

Versioning is
specified at design
time using
transaction SHMA

© SAP AG 2004, SAP TechEd / ABAP251 / 67

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

© SAP AG 2004, SAP TechEd / ABAP251 / 69

 Client Dependency

Client dependency
is specified at
design time using
transaction SHMA

© SAP AG 2004, SAP TechEd / ABAP251 / 70

 Demo

Demo 2

© SAP AG 2004, SAP TechEd / ABAP251 / 71

 Exercise

Exercise 2

© SAP AG 2004, SAP TechEd / ABAP251 / 72

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

© SAP AG 2004, SAP TechEd / ABAP251 / 75

 Transactional Areas Motivation

Database changes
Area
Area instance depending on
database changes Instance

Version
1
Version
2

Database

© SAP AG 2004, SAP TechEd / ABAP251 / 76

 Transactional Areas Motivation

Database changes
Area
Area instance depending on
database changes Instance
Area commit, version 1 gets
out of date Version
1
Version
2

Database

© SAP AG 2004, SAP TechEd / ABAP251 / 77

 Transactional Areas Motivation

Database changes
Area
Area instance depending on
database changes Instance
Area commit, version 1 gets
out of date and expires

Version
2

Database

© SAP AG 2004, SAP TechEd / ABAP251 / 78

 Transactional Areas Motivation

Database changes
Area
Area instance depending on
database changes Instance
Area commit, version 1 gets
out of date and expires

Database rollback Î Version

inconsistency in area instance 2

???

Database

© SAP AG 2004, SAP TechEd / ABAP251 / 79

 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
© SAP AG 2004, SAP TechEd / ABAP251 / 80
 Propagation Motivation

Instances reside on Application Server

instances

Database

AppServer 1 AppServer 2 AppServer 3

Instance Instance Instance

Version 1 Version 1 Version 1

© SAP AG 2004, SAP TechEd / ABAP251 / 81

 Propagation Motivation

Instances reside on Application Server

instances

Instance changes

Database

AppServer 1 AppServer 2 AppServer 3

Instance Instance Instance

Version 1 Version 1 Version 1

Version 2

© SAP AG 2004, SAP TechEd / ABAP251 / 82

 Propagation Motivation

Instances reside on Application Server

instances

Instance changes do not affect other servers

Database

AppServer 1 AppServer 2 AppServer 3

Instance Instance Instance

Version 1 Version 1 Version 1

Version 2

© SAP AG 2004, SAP TechEd / ABAP251 / 83

 Propagation Motivation

Instances reside on Application Server

instances

Instance changes do not affect other servers

Instance mismatch on other application servers

Database

AppServer 1 AppServer 2 AppServer 3

Instance Instance Instance

Version 1 Version 1

Version 2 ??? ???

© SAP AG 2004, SAP TechEd / ABAP251 / 84

 Propagation Solution

Instance changes are not propagated to other

servers, only an invalidation record is sent

Database

AppServer 1 AppServer 2 AppServer 3

Instance Instance Instance

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

© SAP AG 2004, SAP TechEd / ABAP251 / 85

 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

AppServer 1 AppServer 2 AppServer 3

Instance Instance Instance

Version 1 Version 1

Version 2 Version 2 Version 2

© SAP AG 2004, SAP TechEd / ABAP251 / 86

 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.
© SAP AG 2004, SAP TechEd / ABAP251 / 87
 Transactional Areas and Propagation

Transactional Areas
are specified at
design time using
transaction SHMA

Propagation is done
via invalidation
using the
PROPAGATE
methods

© SAP AG 2004, SAP TechEd / ABAP251 / 88

 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.

© SAP AG 2004, SAP TechEd / ABAP251 / 89

Transactional Areas and Propagation
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

© SAP AG 2004, SAP TechEd / ABAP251 / 91

 Displacement

Displacement is
specified at design
time using
transaction SHMA

© SAP AG 2004, SAP TechEd / ABAP251 / 92

Transactional Areas and Propagation
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.

© SAP AG 2004, SAP TechEd / ABAP251 / 94

 Memory Limits

Memory Limits is
specified at design
time using
transaction SHMA

© SAP AG 2004, SAP TechEd / ABAP251 / 95

Transactional Areas and Propagation
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

© SAP AG 2004, SAP TechEd / ABAP251 / 97

 Lifetime

Lifetime is specified
at design time using
transaction SHMA

© SAP AG 2004, SAP TechEd / ABAP251 / 98

 Demo

Demo 3

© SAP AG 2004, SAP TechEd / ABAP251 / 99

 Exercise

Exercise 3

© SAP AG 2004, SAP TechEd / ABAP251 / 100

 Encapsulation

Avoid direct access to shared memory area instances

Session Area
Reader
Instance1
Reader
Instance2
Reader
Instance3
Writer

© SAP AG 2004, SAP TechEd / ABAP251 / 101

 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

© SAP AG 2004, SAP TechEd / ABAP251 / 102

 Area Properties - Overview

The following properties can be specified at design time

„ Versioning
„ Preloading
„ Transactional
„ Propagation
„ Client dependency
„ Displacement
„ Memory limits
„ Lifetime

© SAP AG 2004, SAP TechEd / ABAP251 / 103

 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

© SAP AG 2004, SAP TechEd / ABAP251 / 104

 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

© SAP AG 2004, SAP TechEd / ABAP251 / 105

 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 AG 2004, SAP TechEd / ABAP251 / 106

 SAP Developer Network

Look for SAP TechEd ’04 presentations and videos on

the SAP Developer Network.

Coming in December.

http://www.sdn.sap.com/

© SAP AG 2004, SAP TechEd / ABAP251 / 107

 Questions?

Q&A

© SAP AG 2004, SAP TechEd / ABAP251 / 108

 Feedback
Please complete your session evaluation.

Be courteous — deposit your trash,

and do not take the handouts for the following session.

Thank You !

© SAP AG 2004, SAP TechEd / ABAP251 / 109

 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.

© SAP AG 2004, SAP TechEd / ABAP251 / 110