Session ID: ABAP251
ABAP Shared ObjectsShared Memory Programming Made Easy
Rolf Hammer, SAP AG
Holger Janz, SAP AG
© SAP AG 2004, SAP TechEd / ABAP251 / 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
Monitor shared memory areas
Advanced Features 1
Motivation
Basic Concepts
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
© SAP AG 2004, SAP TechEd / ABAP251 / 6
What is Shared Memory ?
Different kinds of main memory on an application server
Session MemoryBound 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
What is Shared Memory ?
Data Access without Buffering
Data Access with Buffering by Copy
Data Access with in Place Buffering
Benefits for Application Programming
© SAP AG 2004, SAP TechEd / ABAP251 / 8
Data Access without Buffering
User XSession
DB
© SAP AG 2004, SAP TechEd / ABAP251 / 9
Data Access without Buffering
User XSession
DB
Common data
retrieved from DB and
aggregated
© SAP AG 2004, SAP TechEd / ABAP251 / 10
Data Access without Buffering
User YSession
CommonData
User XSession
CommonData
DB
Common data
retrieved from DB and
aggregated for
each user session
User ZSession
CommonData
CommonData
CommonData
What is Shared Memory ?
Data Access without Buffering
Data Access with Buffering by Copy
Data Access with in Place Buffering
Benefits for Application Programming
© SAP AG 2004, SAP TechEd / ABAP251 / 12
Data Access with Buffering by Copy
User XSession
DB
© SAP AG 2004, SAP TechEd / ABAP251 / 13
Data Access with Buffering by Copy
User XSession
CommonData
DB
Common data
retrieved from DB
© SAP AG 2004, SAP TechEd / ABAP251 / 14
Data Access with Buffering by Copy
User XSession
DB
Common data
retrieved from DB,
aggregated
© SAP AG 2004, SAP TechEd / ABAP251 / 15
Data Access with Buffering by Copy
User XSession
CommonData
DB
Common data
retrieved from DB,
aggregated,
copied (EXPORT) to SHM
Shared Memory (SHM)
CommonData
© SAP AG 2004, SAP TechEd / ABAP251 / 16
Data Access with Buffering by Copy
User XSession
CommonData
DB
Common data
retrieved from DB,
aggregated,
copied (EXPORT) to SHM,
and copied (IMPORT) toeach user session
Shared Memory (SHM)
CommonData
User YSession
CommonData
User ZSession
CommonData
What is Shared Memory ?
Data Access without Buffering
Data Access with Buffering by Copy
Data Access with in Place Buffering
Benefits for Application Programming
© SAP AG 2004, SAP TechEd / ABAP251 / 18
Data Access with in Place Buffering
User XSession
DB
Common data
retrieved from DBdirectly into SHM
Shared Memory (SHM)
CommonData
© SAP AG 2004, SAP TechEd / ABAP251 / 19
Data Access with in Place Buffering
DB
Common data
retrieved from DBdirectly into SHM,
aggregated in place
Shared Memory (SHM)
CommonData
User XSession
© SAP AG 2004, SAP TechEd / ABAP251 / 20
Data Access with in Place Buffering
User XSession
DB
Common data
retrieved from DBdirectly into SHM,
aggregated in place
accessed copy-free byother user sessions
Shared Memory (SHM)
CommonData
User YSession
User ZSession
What is Shared Memory ?
Data Access without Buffering
Data Access with Buffering by Copy
Data Access with in Place Buffering
Benefits for Application Programming
© SAP AG 2004, SAP TechEd / ABAP251 / 22
Benefits for Application Programming
Significant boost in overall performance due to
Reduced memory consumptionData is kept only once in memory
Reduced runtime costsData 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 / 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
Simplified code simplifies maintenance
Advanced Features 1
Motivation
Basic Concepts
Advanced Features 2
Usage Scenarios
Areas and Area Instances
Locking Concept
Creating and Accessing Contents
© SAP AG 2004, SAP TechEd / ABAP251 / 26
Usage Scenarios
Main usage scenarios
Shared buffersLow update frequency (e.g. once a day to once per hour) (Very) costly amount of dataMany parallel readers, single writer
Exclusive buffersAccess by a single writer or readerBuffer 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
Areas and Area Instances
Locking Concept
Creating and Accessing Contents
© SAP AG 2004, SAP TechEd / ABAP251 / 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
Instance
Instance
Instance
Shared Object Memory
© SAP AG 2004, SAP TechEd / ABAP251 / 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
Root
© SAP AG 2004, SAP TechEd / ABAP251 / 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 aclass to be generated (e.g. cl_my_area)
Name of root class must be specified (e.g. cl_my_root)
© SAP AG 2004, SAP TechEd / ABAP251 / 31
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 / 32
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 / 33
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
Areas and Area Instances
Locking Concept
Creating and Accessing Contents
© SAP AG 2004, SAP TechEd / ABAP251 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 36
Attaching to an Area Instance
Instance
Root
User YSession
Handle
User XSession
Handle Handle
Provides access to a shared objects area instance
Creates handle object
Sets appropriate lock
Makes reference to rootobject available
Methods
attach_for_readattach_for_writeattach_for_update
© SAP AG 2004, SAP TechEd / ABAP251 / 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 forwrite
Example: Write Access
© SAP AG 2004, SAP TechEd / ABAP251 / 38
Detaching from an Area Instance
Instance
Root
User YSession
Handle
User XSession
Handle Handle
Cancels access to a shared objects area instance
Invalidates handle object
Releases lock
Makes reference to rootobject unavailable
Changes must be committed or rolled back
Methods
detachdetach_commitdetach_rollback
© SAP AG 2004, SAP TechEd / ABAP251 / 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
Usage Scenarios
Areas and Area Instances
Locking Concept
Creating and Accessing Contents
© SAP AG 2004, SAP TechEd / ABAP251 / 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 ENABLEDat 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 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 43
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 / 44
data:myShmHandle type ref to cl_my_area.
myShmHandle = cl_my_area=>attach_for_read( ).
read table myShmHandle->root->itabinto wa index i.
...
myShmHandle->detach( ).
Open defaultinstance for read
Example: Accessing Contents
Access rootobject components
Release lock
© SAP AG 2004, SAP TechEd / ABAP251 / 45
Shared Objects Area Monitor
Shared objects area monitor (transaction SHMM)
Overview on areas, instances, and locks
Content browser
© SAP AG 2004, SAP TechEd / ABAP251 / 46
Demo
Demo 1
© SAP AG 2004, SAP TechEd / ABAP251 / 47
Exercise
Exercise 1
Advanced Features 2
Basic Concepts
Advanced Features 1
Multi Attach
Preloading
Versioning
Client Dependency
© SAP AG 2004, SAP TechEd / ABAP251 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 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_flagchanging attach_tab = attach_tab ).
Multi Attach Example
Multi Attach
Preloading
Versioning
Client Dependency
© SAP AG 2004, SAP TechEd / ABAP251 / 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 aseparate 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 / 54
Preloading
Preloading is specified at design time using transaction SHMA
© SAP AG 2004, SAP TechEd / ABAP251 / 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 andexcp->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.
Preloading Example
Multi Attach
Preloading
Versioning
Client Dependency
© SAP AG 2004, SAP TechEd / ABAP251 / 57
Versioning Example
Instance
Version: active
Reader1
© SAP AG 2004, SAP TechEd / ABAP251 / 58
Versioning Example
Instance
Version: active Version: under construction
WriterReader1
© SAP AG 2004, SAP TechEd / ABAP251 / 59
Versioning Example
Instance
Version: active Version: under construction
WriterReader1
Reader2
© SAP AG 2004, SAP TechEd / ABAP251 / 60
Versioning Example
Instance
Version: out of date
Version: active
Reader1Reader2
© SAP AG 2004, SAP TechEd / ABAP251 / 61
Versioning Example
Instance
Version: out of date
Version: active
Reader1Reader2 Reader3
© SAP AG 2004, SAP TechEd / ABAP251 / 62
Versioning Example
Instance
Version: out of date
Version: active
Reader1Reader3
© SAP AG 2004, SAP TechEd / ABAP251 / 63
Versioning Example
Instance
Version: expired
Version: active
Reader3
© SAP AG 2004, SAP TechEd / ABAP251 / 64
Versioning Example
Instance
Version: active
Reader3
© SAP AG 2004, SAP TechEd / ABAP251 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 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
Strictly speaking a version is an area instance version
© SAP AG 2004, SAP TechEd / ABAP251 / 67
Versioning
Versioning is specified at design time using transaction SHMA
Multi Attach
Preloading
Versioning
Client Dependency
© SAP AG 2004, SAP TechEd / ABAP251 / 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)
Predefined constant to address all clients
© SAP AG 2004, SAP TechEd / ABAP251 / 70
Client Dependency
Client dependency is specified at design time using transaction SHMA
© SAP AG 2004, SAP TechEd / ABAP251 / 71
Demo
Demo 2
© SAP AG 2004, SAP TechEd / ABAP251 / 72
Exercise
Exercise 2
Advanced Features 2
Basic concepts
Advanced Features 1
Transactional Areas and Propagation
Displacement
Memory Limits
Binding
© SAP AG 2004, SAP TechEd / ABAP251 / 75
Transactional Areas Motivation
Instance
Area
Database
Version1
Database changes
© SAP AG 2004, SAP TechEd / ABAP251 / 76
Transactional Areas Motivation
Database
Database changes
Area instance depending on database changes Instance
Area
Version1
Version2
© SAP AG 2004, SAP TechEd / ABAP251 / 77
Transactional Areas Motivation
Database
Database changes
Area instance depending on database changes
Area commit, version 1 gets out of date
Instance
Area
Version1
Version2
© SAP AG 2004, SAP TechEd / ABAP251 / 78
Transactional Areas Motivation
Database
Database changes
Area instance depending on database changes
Area commit, version 1 getsout of date and expires
Instance
Area
Version2
© SAP AG 2004, SAP TechEd / ABAP251 / 79
Transactional Areas Motivation
Database
Database changes
Area instance depending on database changes
Area commit, version 1 getsout of date and expires
Database rollback inconsistency in area instance
Instance
Area
Version2
???
© SAP AG 2004, SAP TechEd / ABAP251 / 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 activev2 under construction
v1 out of datev2 active
DB commitdetach_commit
v1 activev2 pending
Read v2
read v1read v1
write v2
© SAP AG 2004, SAP TechEd / ABAP251 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 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
???
© SAP AG 2004, SAP TechEd / ABAP251 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 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 areasTechnical reason: sync records via database
Conceptual reason: In general propagation will be needed, if area contents depend on database contents
Pull modelReceiving a sync record lets the active version becomeout of dateRebuild 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 / 88
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 / 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.
Transactional Areas and Propagation Example
Transactional Areas and Propagation
Displacement
Memory Limits
Binding
© SAP AG 2004, SAP TechEd / ABAP251 / 91
Displacement
Displacement means that an area instance version with noactive 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 NetWeaverrelease)
Every object must be serializable (tag interface if_serializable_object)Deserialization at the next read request
© SAP AG 2004, SAP TechEd / ABAP251 / 92
Displacement
Displacement is specified at design time using transaction SHMA
Transactional Areas and Propagation
Displacement
Memory Limits
Binding
Lifetime
© SAP AG 2004, SAP TechEd / ABAP251 / 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.
© SAP AG 2004, SAP TechEd / ABAP251 / 95
Memory Limits
Memory Limits is specified at design time using transaction SHMA
Lifetime
Transactional Areas and Propagation
Displacement
Memory Limits
© SAP AG 2004, SAP TechEd / ABAP251 / 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 sharedmemory
© SAP AG 2004, SAP TechEd / ABAP251 / 98
Lifetime
Lifetime is specified at design time using transaction SHMA
© SAP AG 2004, SAP TechEd / ABAP251 / 99
Demo
Demo 3
© SAP AG 2004, SAP TechEd / ABAP251 / 100
Exercise
Exercise 3
© SAP AG 2004, SAP TechEd / ABAP251 / 101
Encapsulation
Reader
Reader
Session Area
Instance1
Instance2
Instance3Reader
Writer
Avoid direct access to shared memory area instances
© SAP AG 2004, SAP TechEd / ABAP251 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 103
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 / 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
© SAP AG 2004, SAP TechEd / ABAP251 / 105
Summary
ABAP Shared Objects is used to share common databetween 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 / 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 2004ABAP201, 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 Opportunitieshttp://www.sap.com/education/
© SAP AG 2004, SAP TechEd / ABAP251 / 107
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 / 108
Q&A
Questions?
© SAP AG 2004, SAP TechEd / ABAP251 / 109
Please complete your session evaluation.
Be courteous — deposit your trash, and do not take the handouts for the following session.
Feedback
Thank You !
© SAP AG 2004, SAP TechEd / ABAP251 / 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 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.
Copyright 2004 SAP AG. All Rights Reserved