ABAP Shared Objects - Shared Memory Programming Made Easy

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

to a single user session be accessed by a different user session

‹ Guarantees

user isolation

„ Shared Memory (SHM) ‹ Shared ‹ No

across session boundaries

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

DB

User X Session

© SAP AG 2004, SAP TechEd / ABAP251 / 9

Data Access without Buffering Common data „ retrieved from DB and „ aggregated for

DB

„ each user session

Common Data

Common Data

Common Data

User X Session

User Y Session

User Z 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, „ aggregated

DB

User X Session

© SAP AG 2004, SAP TechEd / ABAP251 / 14

Data Access with Buffering by Copy Shared Memory (SHM) Common Data

DB

Common data „ retrieved from DB, „ aggregated, „ 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

DB

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

Common Data

Common Data

Common Data

User X Session

User Y Session

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

DB

User X Session

© SAP AG 2004, SAP TechEd / ABAP251 / 18

Common data „ retrieved from DB directly into SHM

Data Access with in Place Buffering Shared Memory (SHM) Common Data

DB

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

User X Session

© SAP AG 2004, SAP TechEd / ABAP251 / 19

Data Access with in Place Buffering Shared Memory (SHM) Common Data

DB

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

User X Session

© SAP AG 2004, SAP TechEd / ABAP251 / 20

User Y Session

User Z Session

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 „ Part of the shared memory

Shared Memory Shared Object 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

© SAP AG 2004, SAP TechEd / ABAP251 / 28

Area I n s t a n c e

Area I n s t a n c e

I n s t a n c e

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

Instance Root

Design Time Support 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)

© SAP AG 2004, SAP TechEd / ABAP251 / 30

Area:

cl_my_area

Instance Root: cl_my_root

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

© SAP AG 2004, SAP TechEd / ABAP251 / 33

cl_my_area2

cl_my_area3

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 objects area instance

Instance Root

„ Creates handle object „ Sets appropriate lock „ Makes reference to root object available

Handle Handle

Handle

User X Session

User Y Session

Methods „ attach_for_read „ attach_for_write „ attach_for_update

© SAP AG 2004, SAP TechEd / ABAP251 / 36

Example: Write Access data: ... myShmHandle type ref to cl_my_area, myRoot type ref to cl_my_root.

Open default instance for 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 Root

„ Invalidates handle object „ Releases lock „ Makes reference to root object unavailable Changes must be committed or rolled back Methods „ detach „ detach_commit „ detach_rollback © SAP AG 2004, SAP TechEd / ABAP251 / 38

Handle Handle

Handle

User X Session

User Y Session

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( ). else. myShmHandle->detach_rollback( ). endif. © SAP AG 2004, SAP TechEd / ABAP251 / 39

Commit changes Rollback changes

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: myShmHandle type ref to cl_my_area.

Open default instance for read

myShmHandle = cl_my_area=>attach_for_read( ). read table myShmHandle->root->itab into wa index i. ... myShmHandle->detach( ).

© SAP AG 2004, SAP TechEd / ABAP251 / 44

Access root object components

Release lock

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 = attach_wa-inst_name = attach_wa-lock_kind = insert attach_wa into

'ZCL_MY_AREA_1'. cl_shm_area=>default_instance. cl_shm_area=>lock_kind_read. table attach_tab.

attach_wa-area_name = attach_wa-inst_name = attach_wa-lock_kind = insert attach_wa into

'ZCL_MY_AREA_2'. cl_shm_area=>default_instance. cl_shm_area=>lock_kind_write. 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

Reader1 © SAP AG 2004, SAP TechEd / ABAP251 / 58

Version: under construction

Writer

Versioning Example Instance Version: active

Reader1 Reader2 © SAP AG 2004, SAP TechEd / ABAP251 / 59

Version: under construction

Writer

Versioning Example Instance Version: out of date

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

Version: active

Versioning Example Instance Version: out of date

Reader1 Reader2 © SAP AG 2004, SAP TechEd / ABAP251 / 61

Version: active

Reader3

Versioning Example Instance Version: out of date

Reader1 © SAP AG 2004, SAP TechEd / ABAP251 / 62

Version: active

Reader3

Versioning Example Instance Version: expired

Version: active

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 construction

active

out of date

expired

© 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 instance depending on database changes

Area Instance Version 1

Database © SAP AG 2004, SAP TechEd / ABAP251 / 76

Version 2

Transactional Areas Motivation Database changes Area instance depending on database changes Area commit, version 1 gets out of date

Database © SAP AG 2004, SAP TechEd / ABAP251 / 77

Area Instance Version 1

Version 2

Transactional Areas Motivation Database changes Area instance depending on database changes

Area 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 instance depending on database changes

Area Instance

Area commit, version 1 gets out of date and expires Database rollback Î inconsistency in area instance

Version 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 v2 under construction

v1 active v2 pending

v1 out of date v2 active

read v1 read v1 Read v2 write v2 detach_commit © SAP AG 2004, SAP TechEd / ABAP251 / 80

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

© 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

version1 1 Version

version1 1 Version

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

© SAP AG 2004, SAP TechEd / ABAP251 / 86

Version 2

Version 2

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 Broker

Instance2

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