Abap Objects by Helen PDF

SAP TechEd ‘03 Basel
Why use ABAP

Objects
Horst Keller, Stefan Bresch

ABAP Language, SAP AG
Learning Objectives
As a result of this workshop, you will

be able to:
Explain the benefits of object oriented programming in

general
Explain the benefits of ABAP Objects compared to
classical ABAP
Understand why Unicode enabled ABAP Objects is the
best language for business applications up to now
 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 2
© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 1

Agenda
Background
Principal Features of ABAP Objects

Encapsulation
Instantiation
Reuse via Inheritance
Interfacing
Events
Benefits of ABAP Objects

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion

Background – History
ABAP Objects was introduced with SAP Basis, Release 4.5.

Classes
Interfaces
Events
ABAP Objects was completed with SAP Basis Release 4.6.
Inheritance
Compound interfaces
Dynamic Invoke
Some enhancements were added with SAP Web Application Server,
Releases 6.10, 6.20, ...
Friends
Object Services
Shared Objects
Æ Preceding TechEd Workshops (available from horst.keller@sap.com)
Background – ABAP and ABAP Objects at the WAS
User Interface
(SAP GUI, Web, ...)
ABAP
Web
...
SELECT * FROM ... Application
... Server
ABAP Objects
Persistent Data
(Database, Files, ...)

Background – Object Orientation in ABAP
Pure
Object
Oriented
ABAP
World ?
ABAP Non-ABAP
Technically possible!
Objects
with
Application
Logic
ABAP

Persistence and
Transaction
Services
provided by
ABAP Object Services,
as of
Release 6.10
GUI Control
Framework,
Office
Integration,
Business
Server
Pages,
etc.
ABAP

For example JavaScript

(as of Release 6.10)
ABAP Non-ABAP
System
Application Classes
Coding from
is here! Libraries

Inside Objects?
METHOD...
DATA ... TYPE ...
...
LOOP AT itab
REFERENCE INTO ...
...
ENDMETHOD.
Purified ABAP
Reality ...
CALL
SCREEN
...
CALL
FUNCTION
DESTINATION
...
SELECT
...
ABAP Non-ABAP
ABAP + ABAP Objects

Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
Encapsulation – ABAP/4 (1)

Encapsulation
Event Driven Modularization of global data
Processes * Global Declarations...

DATA ...
No local data
PROCESS ON ...
MODULE ...
MODULE ...
...
...
ENDMODULE.
START-OF-SELECTION
...
No local data
Runtime
Environment Dynpro ABAP Program

Encapsulation – ABAP/4 (2)

Encapsulation
can be
Procedural Programming Model circumvented!
* Global Declarations ... * Global Declarations ...

DATA ... DATA ...
Encapsulation
MODULE ... FUNCTION ... of global data
... DATA ...
CALL FUNCTION ... ... Local data
PERFORM ... PERFORM ...
... ...
ENDMODULE. ENDFUNCTION.
FORM ...
FORM ... DATA ...
DATA ... ... Local data
... Local data SELECT * FROM ...
ENDFORM. ...
ENDFORM.
ABAP Program Function Group
Encapsulation – Example ABAP/4 (1)
Encapsulation
FUNCTION-POOL account. of an account
DATA current_amount TYPE accounts-amount.
FUNCTION deposit.
current_amount = current_amount + amount. Function
ENDFUNCTION. modules
work with
one account
FUNCTION withdraw.
IF current_amount > amount.
current_amount = current_amount - amount.
ELSE.
RAISE EXCEPTION TYPE cx_negative_amount.
ENDIF.
No possibility
ENDFUNCTION. to interact
with other
accounts
Function Group

FUNCTION-POOL account.
DATA account_tab TYPE SORTED TABLE OF accounts
WITH UNIQUE KEY id.
All data in
LOAD-OF-PROGRAM. one table
SELECT * FROM accounts
INTO TABLE account_tab.
FUNCTION deposit.
DATA account_wa TYPE accounts.
READ TABLE account_tab INTO account_wa
Function
WITH TABLE KEY id = id. modules
account_wa-amount = account_wa-amount + amount. work on
MODIFY TABLE account_tab FROM account_wa.
shared data
ENDFUNCTION.
Function Group
FUNCTION withdraw.
READ TABLE account_tab INTO account_wa
WITH TABLE KEY id = id.
IF account_wa-amount > amount.
account_wa-amount = account_wa-amount - amount.
ELSE.
ENDIF.
ENDFUNCTION.
FUNCTION transfer.
CALL FUNCTION 'WITHDRAW' Data
EXPORTING identified by
id = id_from input
amount = amount.
CALL FUNCTION 'DEPOSIT' parameters
EXPORTING
id = id_to
amount = amount.
ENDFUNCTION.
Function Group

Encapsulation – ABAP Objects
Classes
CLASS ... DEFINITION. CLASS ... DEFINITION.

PUBLIC SECTION. PUBLIC SECTION.
METHODS ... METHODS ...
PRIVATE SECTION. PRIVATE SECTION.
DATA ... DATA ...
... Encapsulation ... Encapsulation
ENDMETHOD. of Attributes ENDMETHOD. of Attributes
ENDCLASS. ENDCLASS.
CLASS ... IMPLEMENTATION. CLASS ... IMPLEMENTATION.

METHOD... METHOD...
DATA ... Local data DATA ... Local data
... ...
CALL METHOD ... SELECT * FROM ...
... ...
ENDMETHOD. ENDMETHOD.
ENDCLASS. ENDCLASS.
ABAP Program Class Pool
Encapsulation – Example ABAP Objects (1)
A class unites
functionality
with data
CLASS account DEFINITION.
PUBLIC SECTION.
METHODS: constructor IMPORTING id TYPE accounts-id,
deposit IMPORTING amount TYPE accounts-amount,
withdraw IMPORTING amount TYPE accounts-amount
RAISING cx_negative_amount,
transfer IMPORTING amount TYPE accounts-amount
target TYPE REF TO account
RAISING cx_negative_amount.
PRIVATE SECTION.
DATA amount TYPE accounts-amount. Only data
ENDCLASS. relevant for one
object is
needed
Class Pool

Encapsulation – Example ABAP Objects (2)
CLASS account IMPLEMENTATION.

METHOD constructor.
Each object is
SELECT SINGLE amount
FROM accounts initialized
INTO (amount) individually
WHERE id = id.
ENDMETHOD.
METHOD deposit.
me->amount = me->amount + amount.
ENDMETHOD.
METHOD withdraw. An object
IF me->amount > amount. works on its
me->amount = me->amount - amount. own data, no
ELSE.
RAISE EXCEPTION TYPE cx_negative_amount. business key
ENDIF. needed
ENDMETHOD.
METHOD transfer.
me->withdraw( amount ).
target->deposit( amount ). An object can
ENDMETHOD. address other
ENDCLASS.
objects
Class Pool
Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion

Instantiation – ABAP/4
External Procedure Calls

Only one
instance of
each
Instances of ... program
programs
with global ... Function group 2
data
Function group 1
CALL FUNCTION ... No explicite

instantiation,
ABAP program no control of
lifetime
Internal session of an ABAP program
External session
Instantiation – Example ABAP/4
DATA: id1(8) TYPE n, First call

id2(8) TYPE n, instantiates
amnt TYPE p DECIMALS 2, function
exc_ref TYPE REF TO cx_negative_amount,
text TYPE string.
group
TRY.
id1 = ...
Business
id2 = ...
amnt = ... keys identify
CALL FUNCTION 'TRANSFER' data
EXPORTING
id_from = id1
id_to = id2
amount = amnt.
No static
CATCH cx_negative_amount INTO exc_ref. type check
text = exc_ref->get_text( ).
MESSAGE text TYPE 'I'.
ENDTRY.
ABAP Program

Instantiation – ABAP Objects
Creation of Objects Many

instances of
one class
Instances of
classes with
attributes and Explicit
an identity instantiation,
control of
lifetime
CREATE OBJECT oref TYPE class.

oref2
oref1
ABAP program
Internal session of an ABAP program

External session
Instantiation – Example ABAP Objects
Object
DATA: account1 TYPE REF TO account,
reference
account2 TYPE REF TO account, variables as
amnt TYPE p DECIMALS 2, explicit handles
exc_ref TYPE REF TO cx_negative_amount,
text TYPE string.
CREATE OBJECT: account1 EXPORTING id = ..., Independent
account2 EXPORTING id = ... objects based
TRY. on the same
amnt = ... class
account1->transfer( EXPORTING amount = amnt
target = account2 ).
CATCH cx_negative_amount INTO exc_ref.
text = exc_ref->get_text( ). Static type
ENDTRY. check
Natural
working with
instances
ABAP Program

Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
Reuse – ABAP/4
Reuse of generalized procedures

No support for specialization
Typical results:
Large function groups
Extensive parameter interfaces
Subdividing tasks via CASE

Reuse – Example ABAP/4 (1)
FUNCTION withdraw.
*"--------------------------------------------------------------
*" IMPORTING
*" REFERENCE(ID) TYPE ACCOUNTS-ID Steering
*" REFERENCE(KIND) TYPE C DEFAULT 'C‚
*" REFERENCE(AMOUNT) TYPE ACCOUNTS-AMOUNT parameters
*" RAISING
*" CX_NEGATIVE_AMOUNT
*" CX_UNKNOWN_ACCOUNT_TYPE Additional
*"--------------------------------------------------------------exception
CASE kind.
WHEN 'C'. „Checking account
PERFORM withdraw_from_checking_account USING id amount.
WHEN 'S'. "Savings account
PERFORM withdraw_from_saving_account USING id amount.
WHEN OTHERS.
RAISE EXCEPTION TYPE cx_unknown_account_type.
ENDCASE. Procedure
ENDFUNCTION. calls with
parameter
passing
Function Group
Reuse – Example ABAP/4 (2)
FORM withdraw_from_checking_account
USING l_id TYPE accounts-id
l_amount TYPE accounts-amount.
READ TABLE account_tab INTO account_wa WITH TABLE KEY id = l_id.
account_wa-amount = account_wa-amount - l_amount.
IF account_wa-amount < 0.
... " handle debit balance
ENDIF.
ENDFORM. Specialized
FORM withdraw_from_savings_account procedures,
USING l_id TYPE accounts-id no code
l_amount TYPE accounts-amount
RAISING cx_negative_amount. reuse
READ TABLE account_tab INTO account_wa WITH TABLE KEY id = l_id.
IF account_wa-amount > l_amount.
account_wa-amount = account_wa-amount - l_amount.
ELSE.
ENDIF.
ENDFORM.
Function Group

Reuse – ABAP Objects
Reuse of general classes

Specialization via inheritance
Benefits
Small classes
Minimal parameter interfaces
Polymorphism (CASE-less programming)
enhanced Modeling capabilities
Reuse – Example ABAP Objects (1)
General superclass
PUBLIC SECTION.
...
PROTECTED SECTION.
DATA amount TYPE accounts-amount.
Data sharing
ENDCLASS. with subclasses
CLASS account IMPLEMENTATION.

...
METHOD withdraw. General method
me->amount = me->amount - amount.
ENDMETHOD. implementation
...
ENDCLASS.
Class Pool

Special subclass
CLASS checking_account DEFINITION
INHERITING FROM account.
PUBLIC SECTION.
METHODS withdraw REDEFINITION. Method
ENDCLASS. redefinition
CLASS checking_account IMPLEMENTATION.

METHOD withdraw. Call of general
super->withdraw( amount ). implementation
IF me->amount < 0.
... " handle debit balance
ENDIF.
ENDMETHOD.
ENDCLASS. Special method
implementation
Class Pool
Special subclass
CLASS savings_account DEFINITION
PUBLIC SECTION.
METHODS withdraw REDEFINITION. Method
ENDCLASS. redefinition
CLASS savings_account IMPLEMENTATION.

METHOD withdraw. Special method
IF me->amount > amount. implementation
super->withdraw( amount ).
ELSE.
ENDIF.
Call of general
ENDMETHOD. implementation
ENDCLASS.
Class Pool

Same object
DATA: account1 TYPE REF TO account,
account2 TYPE REF TO account,
reference
amnt TYPE p DECIMALS 2, variables as
exc_ref TYPE REF TO cx_negative_amount, before
text TYPE string.
CREATE OBJECT: account1 TYPE checking_account
EXPORTING id = ..., General
account2 TYPE savings_account handles for
EXPORTING id = ... specialized
TRY. objects
amnt = ...
account1->transfer( EXPORTING amount = amnt
target = account2 ).
CATCH cx_negative_amount INTO exc_ref.
text = exc_ref->get_text( ).
Same usage of
ENDTRY. objects as
before!
Polymorphism
ABAP Program
Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion

Interfaces – ABAP/4
Limited support for interfaces:

Global data as interfaces between programs
Selection screens as interfaces for executable programs
Parameter interfaces for procedures
No standalone interfaces
Interfaces – ABAP Objects (1)
The interface of a class to the outside is defined by

its public section
The interface of a class allows access to data and
functionality
The interface of a class is inherited from its
superclasses
Interfaces can be defined standalone

Standalone Interfaces
INTERFACE if1. INTERFACE if2.
METHODS: m1 ... METHODS: m2 ...
... ...
ENDINTERFACE. ENDINTERFACE.
CLASS cl_....
INTERFACES: if1,
if2.
...
ENDINTERFACE. METHOD
if1~m1.
...
METHOD
if2~m2.
oref1 oref2 ...
DATA:
oref1 TYPE REF TO if1,
oref2 TYPE REF TO if2.
Benefits of standalone interfaces:

Can be defined by client
Independency from implementation
Polymorphism
Separation of independent characteristics

Interfaces – Example (1)

PUBLIC SECTION.
INTERFACES if_serializable_object.
...
ENDCLASS.
Class Pool
One interface in
different
classes
CLASS customer DEFINITION.
PUBLIC SECTION.
INTERFACES if_serializable_object.
...
ENDCLASS.
Class Pool
Interfaces – Example (2)
Interface
reference
DATA: account TYPE REF TO account,
customer TYPE REF TO customer, variables
serializable_objects TYPE TABLE
OF REF TO if_serializable_object,
serializable_object TYPE REF TO if_serializable_object,
xmlstr TYPE string.
CREATE OBJECT: account EXPORTING id = ...,
customer. Instantiation of
classes
APPEND: account TO serializable_objects,
customer TO serializable_objects.
... Collection of
LOOP AT serializable_objects INTO serializable_object. references to
CALL TRANSFORMATION id objects of
SOURCE obj = serializable_object different classes
RESULT XML xmlstr.
ENDLOOP.
Polymorphism
ABAP Program

Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
Events – ABAP/4
Classical Runtime Events:

PAI, PBO
Selection Screen Events
Reporting Events
List Events
No program defined events

No triggering of events in program

Events – ABAP Objects (1)
Events are components of classes
METHOD... METHODS handler

... FOR EVENT evt ...
RAISE EVENT evt
METHOD handler
...
...
ENDMETHOD.
ENDMETHOD.
oref2
oref1
METHOD...
...
SET HANDLER
oref1->handler FOR oref2.
...
ENDMETHOD.
Events – ABAP Objects (2)
Benefits of events in ABAP Objects:

indirect method call
decoupling of caller and handler
two stages of publish and subscribe
explicit exporting parameters

Events – Example (1)
CLASS checking_account DEFINITION

PUBLIC SECTION.
Allows the class to
METHODS deposit REDEFINITION.
... publish an event
EVENTS consulting_required
EXPORTING value(amount) TYPE accounts-amount.
PRIVATE SECTION.
DATA limit TYPE accounts-amount VALUE '5000.00'.
ENDCLASS.
CLASS checking_account IMPLEMENTATION.

... METHOD deposit.
super->deposit( amount ). Announces a
IF me->amount > limit. state change
RAISE EVENT consulting_required that requires an
EXPORTING amount = me->amount.
ENDIF.
action
ENDMETHOD.
ENDCLASS.
Class Pool
Events – Example (2)
CLASS consultant DEFINITION.

PUBLIC SECTION.
METHODS constructor. Static subscription,
... allows the class to
PRIVATE SECTION.
... handle an event
METHODS receive_notification
FOR EVENT consulting_required OF checking_account.
ENDCLASS.
CLASS consultant IMPLEMENTATION.

METHOD constructor. Dynamic
... subscription
IF ...
SET HANDLER me->receive_notification FOR ALL INSTANCES.
ENDIF ...
ENDMETHOD.
...
METHOD receive_notification.
" do something
ENDMETHOD. Event handling
ENDCLASS.
Class Pool

Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
Simplicity – ABAP/4 (1)
ABAP/4 coding might be simple, but ...
REPORT simple_report.
NODES spfli.
GET spfli.
WRITE: / spfli-carrid, spfli-connid ...
ABAP Program
... who knows really what’s happening here?

Simplicity – ABAP/4 (2)
This is what happens after SUBMIT:

Program is loaded, start values are set In parallel,
LOAD-OF-PROGRAM subroutines of a
Selection screen values are set
logical database
INITIALIZATION
are implicitly
Call of selection screen
called!
AT SELECTION-SCREEN ...
START-OF-SELECTION Still simplified

scheme!
GET spfli
The exact program
flow depends on
END-OF-SELECTION
different settings
Call of list processing for basic list
AT LINE-SELECTION, ...
Simplicity – ABAP Objects
ABAP Objects is simple because:

There are only a few orthogonal basic concepts
Classes contain attributes and methods
Objects are instances of classes
Objects are adressed via references
Accessibility is clearly defined by the object’s interface
Programming with objects is more natural than

handling data via procedures

Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
Explicitness
ABAP/4 has many implicit features, e.g.:

Implicit interfaces via global data
Dynpros
Logical Databases
Programs are controlled by runtime environment

Programs are driven from Dynpros
Program execution via SUBMIT
ABAP Objects is explicit

no hidden concepts
no “black magic”

Explicitness – Example (1)
Classes instead of logical data bases Simple example for

a class that works
like a logical
CLASS ldb DEFINITION. database with a
PUBLIC SECTION. single node
METHODS read_spfli.
EVENTS spfli_ready EXPORTING value(values) TYPE spfli.
PRIVATE SECTION.
DATA spfli_wa TYPE spfli.
ENDCLASS. Explicit Interface
CLASS ldb IMPLEMENTATION.

METHOD read_spfli.
SELECT * FROM spfli
INTO spfli_wa.
RAISE EVENT spfli_ready EXPORTING values = spfli_wa.
ENDSELECT.
ENDMETHOD.
ENDCLASS.
Events with parameters

Class Pool
Class instead of report program
Simple example for Start via an OO

a class that works Transaction
like a report
Explicit event
CLASS report DEFINITION.
PUBLIC SECTION.
handling
METHODS start.
PRIVATE SECTION.
DATA spfli_tab TYPE TABLE OF spfli.
METHODS: get_spfli FOR EVENT spfli_ready OF ldb
IMPORTING values,
display_spfli.
ENDCLASS. Decoupling of data
display from data
ABAP Program handling

CLASS report IMPLEMENTATION.

METHOD start.
DATA ldb TYPE REF TO ldb.
CREATE OBJECT ldb.
SET HANDLER me->get_spfli FOR ldb.
ldb->read_spfli( ).
display_spfli( ). Simplicity does not
ENDMETHOD. necessarily mean
METHOD get_spfli. less coding
APPEND values TO spfli_tab.
ENDMETHOD.
METHOD display_spfli.
DATA alv_list TYPE REF TO cl_gui_alv_grid.
CREATE OBJECT alv_list
EXPORTING i_parent = cl_gui_container=>screen0.
alv_list->set_table_for_first_display(
EXPORTING i_structure_name = 'SPFLI‚
CHANGING it_outtab = spfli_tab ).
CALL SCREEN 100.
ENDMETHOD.
ENDCLASS.
ABAP Program
Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion

Maintainability
Programs using ABAP Objects are

easier to maintain
program structure better readable
better navigation
more reliable
encapsulation
secure typing
surprise free
Maintainability – Program Structure
CLASS ... DEFINITION.

Declaration
PUBLIC SECTION. mandatory
No declaration METHODS: m1 ...
PRIVATE SECTION.
of procedures METHODS: m2 ...
m3 ...
FUNCTION f1.
ENDCLASS.
PERFORM s1 ...
ENDFUNCTION. CLASS ... IMPLEMENTATION.
METHOD m1.
FORM s1 ...
...
... Navigation
m2( ... ).
PERFORM f2 ...
...
...
ENDMETHOD.
ENDFORM.
Mixture of METHOD m2.
FORM s2 ... different ...
... m3( ... ).
PERFORM s3
procedures ...
... ENDMETHOD.
ENDFORM. METHOD m3.
...
FORM s3 ... ENDMETHOD.
...
ENDFORM. ENDCLASS. Only methods
Function Group Class Pool


Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
Purified ABAP - Syntax (1)
ABAP/4 has developed over a long period of time

large number of obsolete statements
overlapping concepts
highly specialized concepts
surprising implicit behavior
difficult to learn

Purified ABAP - Syntax (2)
ABAP Objects reduces the complexity of ABAP

many obsolete statements and additions are forbidden
many implicit syntax completions must be done explicit
wrong handling of data is restricted
Purified ABAP – Syntax Examples (1)
Clean-Up in ABAP Objects

No implicit work areas
No internal tables with header lines Æ explicit
specification of work areas
No TABLES work areas Æ no data sharing between
programs, explicit specification of work areas in Open
SQL , ...
Obsolete
Two data objects declaration!
with one name!
DATA BEGIN OF itab OCCURS 10. DATA itab TYPE TABLE OF ...
... ...
CLEAR itab. CLEAR itab.
TABLES dbtab. DATA wa TYPE dbtab.

SELECT * FROM dbtab. SELECT * FROM dbtab INTO wa.
Inappropriate
ABAP/4 ABAP Objects
short forms


No implicit typing of field-symbols and formal
parameters
Unexpected
behavior!
FIELD-SYMBOLS <fs>. FIELD-SYMBOLS <fs> TYPE ANY.

IF <fs> IS ASSIGNED. IF <fs> IS ASSIGNED.
... ...
ENDIF. ENDIF.
ABAP/4 ABAP Objects

Expected
behavior!

No wrong data handling
DATA number TYPE i VALUE ...

DATA number TYPE i VALUE ...
TRANSLATE number
TO UPPER CASE. TRANSLATE number
TO UPPER CASE.
ABAP/4 ABAP Objects
Undefined Syntax error

behavior!

Purified ABAP - Semantics
Unicode-enabled ABAP
Static type checks specified more precisely
Byte and character strings processed separately
Structures handled appropriately for their type
using structural equivalence rules
Uncontrolled memory manipulation no longer
permitted
Purified Semantics – Example (1)
Structures are assigned fragment by fragment
DATA: BEGIN OF struc1,
col1(2) TYPE c VALUE 'AB',
col2(2) TYPE c VALUE 'CD',
END OF struc1.
DATA: BEGIN OF struc2, Code page
col1(4) TYPE c, dependent
col2 TYPE i, representation of
END OF struc2.
blanks
struc2 = struc1.
Æ struc2 in non-Unicode-enabled ABAP: ABCD ####
Æ struc2 in Unicode-enabled ABAP: ABCD 0
Type specific

Purified Semantics – Example (2)
No access to memory outside a data object
DATA: text1(10) TYPE c,
text2(10) TYPE c VALUE 'ABCDEFGHIJ',
off TYPE i.
FIELD-SYMBOLS <fs> TYPE c.
DO 15 TIMES. Memory
off = sy-index - 1.
ASSIGN text1+off(1) TO <fs>. overwriting,
IF <fs> IS ASSIGNED. even for
<fs> = 'X'. references!
ENDIF.
ENDDO.
Æ text2 in non-Unicode-enabled ABAP: XXXXXFGHIJ
Æ text2 in Unicode-enabled ABAP: ABCDEFGHIJ
Memory protection
Purified Syntax + Purified Semantics
Unicode-enabled ABAP Objects!

Unicode-enabled ABAP Objects is the best ABAP
available up to now!
If you use Unicode-enabled ABAP Objects, you
program automatically according to the rules of
purified syntax and semantics
Even if you do not exploit the real “object oriented”
features, programs written in Unicode-enabled
ABAP Objects are
more robust
less error prone
better to maintain

Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
Future Orientation
(Unicode enabled) ABAP Objects is part of an

ongoing evolution
Don‘t get
lost!
Migration
R/2 ABAP ABAP/4 ABAP Objects Unicode enabled Possible future

developments

Next Topic
Background

Encapsulation
Instantiation
Interfacing
Events

Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
Conclusion - Summary
ABAP Objects offers

better encapsulation
better interfaces
better techniques for reuse
more static type security
support for multiple instantiation
better support for dynamic programming

Conclusion - Recommendation
Everybody programming in ABAP should

use ABAP Objects for new and ongoing
projects
take advantage of object oriented features
use methods as far as possible, even if you stay
within the procedural programming model
do not use subroutines any more
use function modules only when technically
necessary (RFC, encapsulation of screens etc.)
disentangle classical ABAP from ABAP Objects
Appendix
Stricter syntax in ABAP Objects
Stricter syntax in Unicode programs
Example for encapsulation of screens

Appendix A – Stricter Syntax in ABAP Objects (1/2)
Notation: No special characters in names, no length specifications

<= zero, no multi-line literals
Declarations: LIKE references to data objects only; no implicit
lengths or decimal places in TYPES; no length specifications for data
types i, f, d, or t; no operational statements in structure definitions;
FIELDS, RANGES, INFOTYPES, TABLES, NODES, COMMON PART, OCCURS, NON-
LOCAL not permitted
Forbidden operations: CLEAR … WITH NULL, PACK, MOVE ...
PERCENTAGE, ADD-CORRESPONDING, DIVIDE-CORRESPONDING, SUBTRACT-
CORRESPONDING, MULTIPLY-CORRESPONDING, ADD THEN ... UNTIL ...,
ADD FROM ... TO ..., CONVERT {DATE|INVERTED DATE}
String processing: Not permitted on numeric data objects
Field symbols: No implicit types; FIELD-SYMBOLS … STRUCTURE,
ASSIGN ... TYPE, ASSIGN LOCAL COPY OF, ASSIGN TABLE FIELD not
permitted
Logic expressions: ><, =<, => not permitted, table used with IN
must be a selection table
Control structures: No operational statements between CASE and
WHEN, ON-ENDON not permitted
Appendix A – Stricter Syntax in ABAP Objects (2/2)
Internal tables: No headers, no implicit work areas, no redundant

key specifications, compatible work areas where necessary,
obsolete READ variants and COLLECT ... SORTED BY, WRITE TO itab,
PROVIDE (short form) not permitted
Procedures (methods): No implicit type assignment, compatible
initial values only, passing sy-subrc not permitted, raising
undefined exceptions not permitted
Program calls: No joint use of USING and SKIP FIRST SCREEN when
calling transactions, passing formal parameters implicitly in CALL
DIALOG not permitted
Database accesses: No implicit work areas, no *-work areas, READ,
LOOP, REFRESH FROM on database tables not permitted, VERSION
addition to DELETE and MODIFY not permitted, no PERFORMING addition
in Native SQL
Data cluster: No implicit identifiers, passing parameters explicitly
not permitted, no implicit work areas, MAJOR-ID and MINOR-ID not
permitted
Lists: DETAIL, SUMMARY, INPUT, MAXIMUM, MINIMUM, SUMMING, MARK, NEW-
SECTION and obsolete print parameters not permitted

Appendix B – Stricter Syntax in Unicode Programs

Offset/length accesses: Only performed on character-type or byte-type
ranges, and only on flat character-type initial parts of structures
Memory accesses: No access to memory outside a data object
Separation of byte string and character string processing: Explicit
specification with IN BYTE MODE or IN CHARACTER MODE ; appropriate types
expected – for character strings this means only c, d, n, t, string, and
flat structures with purely character-type components
Structures: When assigning and comparing you must take the Unicode
fragment view into consideration
File interface: Implicitly opening files not permitted; access, storage, and
coding type must be specified explicitly; no write access to read-only
files
Conversions: TRANSLATE ... CODE PAGE ..., TRANSLATE ... NUMBER
FORMAT ... not permitted
OPEN SQL: Stricter conditions for work areas
Type assignment using STRUCTURE: Stricter checks on assignments to
field symbols and formal parameters typed using STRUCTURE
Function module calls: A specified formal parameter of a function module
must be available
Appendix C – Encapsulation of Screens (1)

Encapsulation of screens in function groups
FUNCTION-POOL flight_screens. Selection
SELECTION-SCREEN BEGIN OF SCREEN 100 AS WINDOW. Screen
PARAMETERS: p_carrid TYPE sflight-carrid,
p_connid TYPE sflight-connid,
p_fldate TYPE sflight-fldate. Interface
SELECTION-SCREEN END OF SCREEN 100. data for
TABLES sflight. dynpro
FUNCTION get_flight_parameters.
CALL SELECTION-SCREEN 100 STARTING AT 10 10.
... " checks
carrid = p_carrid. Screen
connid = p_connid. handling in
fldate = p_fldate.
ENDFUNCTION. function
FUNCTION get_plane_type.
modules
sflight-planetype = plane_type.
... " preparation
CALL SCREEN 200 STARTING AT 10 10. Further step:
... " checks
plane_type = sflight-planetype.
Local classes in
ENDFUNCTION. function group as
screen handlers
Function Group

Appendix C – Encapsulation of Screens (2)

Object driven usage of screens
CLASS flights IMPLEMENTATION.
CLASS flights DEFINITION. METHOD constructor.
PUBLIC SECTION. DATA: carrid TYPE sflight-carrid,
METHODS: constructor, connid TYPE sflight-connid,
change_plane_type. fldate TYPE sflight-fldate.
PRIVATE SECTION. CALL FUNCTION 'GET_FLIGHT_PARAMETERS'
DATA flight TYPE sflight. IMPORTING
ENDCLASS. carrid = carrid
connid = connid
fldate = fldate.
SELECT SINGLE *
FROM sflight
INTO flight
Call of WHERE carrid = carrid AND
functions with connid = connid AND
parameters fldate = fldate.
ENDMETHOD.
METHOD change_plane_type.
CALL FUNCTION 'GET_PLANE_TYPE'
CHANGING
plane_type = flight-planetype.
ENDMETHOD.
Class Pool ENDCLASS.
Further Information
Î ABAP Documentation:
Always the first source of information
Î Articles in Journals:
http://www.intelligenterp.com/feature/archive/heymann.shtml
http://www.intelligenterp.com/feature/archive/keller.shtml
http://www.sappublications.com/insider/article.htm?key=20248
Î SAP Press Books:

ABAP Objects, Introduction:
ISBN 0-201-75080-5 (English)
ISBN 3-89842-147-3 (German)
ABAP Objects, Reference:
ISBN 1-59229-011-6 (English)
ISBN 3-934358-61-6 (German)

Questions?
Q&A
Feedback
Please complete your session evaluation and

drop it in the box on your way out.
Thank You !
The SAP TechEd ’03 Basel Team

Copyright 2003 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®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® 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®, Informix
and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA 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®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and
other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML 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.
MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.
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.

Abap Objects by Helen PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Abap Objects by Helen PDF

Uploaded by

Copyright:

Available Formats

SAP TechEd ‘03 Basel

Why use ABAP

Horst Keller, Stefan Bresch

As a result of this workshop, you will

 Explain the benefits of object oriented programming in

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 2

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 1

Principal Features of ABAP Objects

Benefits of ABAP Objects

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 3

Principal Features of ABAP Objects

Benefits of ABAP Objects

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 4

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 2

 ABAP Objects was introduced with SAP Basis, Release 4.5.

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 5

Background – ABAP and ABAP Objects at the WAS

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 6

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 3

Background – Object Orientation in ABAP

Background – Object Orientation in ABAP

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 8

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 4

Background – Object Orientation in ABAP

Background – Object Orientation in ABAP

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 10

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 5

Background – Object Orientation in ABAP

For example JavaScript

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 11

Background – Object Orientation in ABAP

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 12

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 6

Background – Object Orientation in ABAP

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 13

Background – Object Orientation in ABAP

ABAP + ABAP Objects

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 14

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 7

Principal Features of ABAP Objects

Benefits of ABAP Objects

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 15

Encapsulation – ABAP/4 (1)

Processes * Global Declarations...

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 16

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 8

Encapsulation – ABAP/4 (2)

* Global Declarations ... * Global Declarations ...

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 17

Encapsulation – Example ABAP/4 (1)

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 9

Encapsulation – Example ABAP/4 (2)

Encapsulation – Example ABAP/4 (3)

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 10

Encapsulation – ABAP Objects

CLASS ... DEFINITION. CLASS ... DEFINITION.

CLASS ... IMPLEMENTATION. CLASS ... IMPLEMENTATION.

ABAP Program Class Pool

 SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 21

Encapsulation – Example ABAP Objects (1)

© 2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 11

Encapsulation – Example ABAP Objects (2)

CLASS account IMPLEMENTATION.

Explain the benefits of object oriented programming in

ABAP Objects was introduced with SAP Basis, Release 4.5.

Reuse of generalized procedures

Reuse of general classes

Limited support for interfaces:

The interface of a class to the outside is defined by

Benefits of standalone interfaces:

Separation of independent characteristics

Classical Runtime Events:

No program defined events