Why Use ABAP Object by Horst Keller

SAP TechEd 03 Basel
2003 SAP AG ABAP 256, Stefan Bresch, Horst Keller 1

Why use ABAP
Objects
Horst Keller, Stefan Bresch
ABAP Language, SAP AG
SAP AG 2003, TechED_Basel / ABAP256, Horst Keller, Stefan Bresch / 2
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 TechEd 03 Basel
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
SAP TechEd 03 Basel
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
Persistent Data
(Database, Files, ...)
User Interface
(SAP GUI, Web, ...)
Web
Application
Server
...
SELECT * FROM ...
...
ABAP
ABAP Objects
SAP TechEd 03 Basel
Background Object Orientation in ABAP
Pure
Object
Oriented
ABAP
World ?
ABAP
Non-ABAP
Technically possible!
ABAP
Objects
with
Application
Logic
SAP TechEd 03 Basel
ABAP
Persistence and
Transaction
Services
provided by
Object Services,
as of
Release 6.10
ABAP
GUI Control
Framework,
Office
Integration,
Business
Server
Pages,
etc.
SAP TechEd 03 Basel
ABAP
Non-ABAP
For example JavaScript
(as of Release 6.10)
System
Classes
from
Libraries
Application
Coding
is here!
SAP TechEd 03 Basel
Purified ABAP
Inside Objects?
METHOD...
DATA ... TYPE ...
...
LOOP AT itab
REFERENCE INTO ...
...
ENDMETHOD.
Reality ...
ABAP + ABAP Objects
ABAP
Non-ABAP
CALL
FUNCTION
DESTINATION
...
CALL
SCREEN
...
SELECT
...
SAP TechEd 03 Basel
Next Topic
Background
Encapsulation
Instantiation
Interfacing
Events
Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
Encapsulation ABAP/4 (1)
ABAP Program
* Global Declarations...
DATA ...
Event Driven Modularization
Runtime
Environment Dynpro
PROCESS ON ...
MODULE ...
...
MODULE ...
...
ENDMODULE.
START-OF-SELECTION
...
No local data
No local data
Processes
Encapsulation
of global data
SAP TechEd 03 Basel
Encapsulation ABAP/4 (2)
ABAP Program
* Global Declarations ...
DATA ...
Procedural Programming Model
FORM ...
DATA ...
...
ENDFORM.
Function Group
* Global Declarations ...
DATA ...
FORM ...
DATA ...
...
SELECT * FROM ...
...
ENDFORM.
MODULE ...
...
CALL FUNCTION ...
PERFORM ...
...
ENDMODULE.
FUNCTION ...
DATA ...
...
PERFORM ...
...
ENDFUNCTION.
Local data
Local data
Local data
Encapsulation
of global data
Encapsulation
can be
circumvented!
Encapsulation Example ABAP/4 (1)
Function Group
FUNCTION-POOL account.
DATA current_amount TYPE accounts-amount.
Encapsulation
of an account
FUNCTION deposit.
current_amount = current_amount + amount.
ENDFUNCTION.
Function
modules
work with
one account
FUNCTION withdraw.
IF current_amount > amount.
current_amount = current_amount - amount.
ELSE.
RAISE EXCEPTION TYPE cx_negative_amount.
ENDIF.
ENDFUNCTION.
No possibility
to interact
with other
accounts
SAP TechEd 03 Basel
Function Group
FUNCTION-POOL account.
DATA account_tab TYPE SORTED TABLE OF accounts
WITH UNIQUE KEY id.
LOAD-OF-PROGRAM.
SELECT * FROM accounts
INTO TABLE account_tab.
All data in
one table
FUNCTION deposit.
DATA account_wa TYPE accounts.
READ TABLE account_tab INTO account_wa
WITH TABLE KEY id = id.
account_wa-amount = account_wa-amount + amount.
MODIFY TABLE account_tab FROM account_wa.
ENDFUNCTION.
Function
modules
work on
shared data
Function Group
FUNCTION transfer.
CALL FUNCTION 'WITHDRAW'
EXPORTING
id = id_from
amount = amount.
CALL FUNCTION 'DEPOSIT'
EXPORTING
id = id_to
amount = amount.
ENDFUNCTION.
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.
Data
identified by
input
parameters
Data
identified by
input
parameters
SAP TechEd 03 Basel
Encapsulation ABAP Objects
ABAP Program
Classes
Class Pool
CLASS ... DEFINITION.
PUBLIC SECTION.
METHODS ...
PRIVATE SECTION.
DATA ...
...
ENDMETHOD.
ENDCLASS.
CLASS ... IMPLEMENTATION.
METHOD...
DATA ...
...
SELECT * FROM ...
...
ENDMETHOD.
ENDCLASS.
PUBLIC SECTION.
METHODS ...
PRIVATE SECTION.
DATA ...
...
ENDMETHOD.
ENDCLASS.
METHOD...
DATA ...
...
CALL METHOD ...
...
ENDMETHOD.
ENDCLASS.
Local data Local data
Encapsulation
of Attributes
Encapsulation
of Attributes
Encapsulation Example ABAP Objects (1)
Class Pool
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.
ENDCLASS.
A class unites
functionality
with data
Only data
relevant for one
object is
needed
SAP TechEd 03 Basel
Encapsulation Example ABAP Objects (2)
Class Pool
CLASS account IMPLEMENTATION.
METHOD constructor.
SELECT SINGLE amount
FROM accounts
INTO (amount)
WHERE id = id.
ENDMETHOD.
METHOD deposit.
me->amount = me->amount + amount.
ENDMETHOD.
METHOD withdraw.
IF me->amount > amount.
me->amount = me->amount - amount.
ELSE.
ENDIF.
ENDMETHOD.
METHOD transfer.
me->withdraw( amount ).
target->deposit( amount ).
ENDMETHOD.
ENDCLASS.
Each object is
initialized
individually
An object
works on its
own data, no
business key
needed
An object can
address other
objects
Next Topic
Background
Encapsulation
Instantiation
Interfacing
Events
Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
SAP TechEd 03 Basel
Instantiation ABAP/4
External Procedure Calls
External session
Internal session of an ABAP program
CALL FUNCTION ...
ABAP program
...
...
Function group 1
Function group 2
Instances of
programs
with global
data
No explicite
instantiation,
no control of
lifetime
Only one
instance of
each
program
Instantiation Example ABAP/4
ABAP Program
DATA: id1(8) TYPE n,
id2(8) TYPE n,
amnt TYPE p DECIMALS 2,
exc_ref TYPE REF TO cx_negative_amount,
text TYPE string.
TRY.
id1 = ...
id2 = ...
amnt = ...
CALL FUNCTION 'TRANSFER'
EXPORTING
id_from = id1
id_to = id2
amount = amnt.
CATCH cx_negative_amount INTO exc_ref.
text = exc_ref->get_text( ).
MESSAGE text TYPE 'I'.
ENDTRY.
First call
instantiates
function
group
Business
keys identify
data
No static
type check
SAP TechEd 03 Basel
Instantiation ABAP Objects
Creation of Objects
External session
Internal session of an ABAP program
CREATE OBJECT oref TYPE class.
ABAP program
Instances of
classes with
attributes and
an identity
Explicit
instantiation,
control of
lifetime
oref1
oref2
Many
instances of
one class
Instantiation Example ABAP Objects
ABAP Program
DATA: account1 TYPE REF TO account,
account2 TYPE REF TO account,
text TYPE string.
CREATE OBJECT: account1 EXPORTING id = ...,
account2 EXPORTING id = ...
TRY.
amnt = ...
account1->transfer( EXPORTING amount = amnt
target = account2 ).
ENDTRY.
Object
reference
variables as
explicit handles
Independent
objects based
on the same
class
Static type
check
Natural
working with
instances
SAP TechEd 03 Basel
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
SAP TechEd 03 Basel
Reuse Example ABAP/4 (1)
Function Group
FUNCTION withdraw.
*"--------------------------------------------------------------
*" IMPORTING
*" REFERENCE(ID) TYPE ACCOUNTS-ID
*" REFERENCE(KIND) TYPE C DEFAULT 'C
*" REFERENCE(AMOUNT) TYPE ACCOUNTS-AMOUNT
*" RAISING
*" CX_NEGATIVE_AMOUNT
*" CX_UNKNOWN_ACCOUNT_TYPE
*"--------------------------------------------------------------
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.
ENDFUNCTION.
Steering
parameters
Additional
exception
Procedure
calls with
parameter
passing
Reuse Example ABAP/4 (2)
Function Group
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.
FORM withdraw_from_savings_account
USING l_id TYPE accounts-id
l_amount TYPE accounts-amount
RAISING cx_negative_amount.
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.
Specialized
procedures,
no code
reuse
Specialized
procedures,
no code
reuse
SAP TechEd 03 Basel
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)
Class Pool
PUBLIC SECTION.
...
PROTECTED SECTION.
DATA amount TYPE accounts-amount.
ENDCLASS.
Data sharing
with subclasses
CLASS account IMPLEMENTATION.
...
METHOD withdraw.
me->amount = me->amount - amount.
ENDMETHOD.
...
ENDCLASS.
General method
implementation
General superclass
SAP TechEd 03 Basel
Class Pool
CLASS checking_account DEFINITION
INHERITING FROM account.
PUBLIC SECTION.
METHODS withdraw REDEFINITION.
ENDCLASS.
Method
redefinition
CLASS checking_account IMPLEMENTATION.
METHOD withdraw.
super->withdraw( amount ).
IF me->amount < 0.
... " handle debit balance
ENDIF.
ENDMETHOD.
ENDCLASS.
Special method
implementation
Special subclass
Call of general
implementation
Class Pool
CLASS savings_account DEFINITION
PUBLIC SECTION.
METHODS withdraw REDEFINITION.
ENDCLASS.
Method
redefinition
CLASS savings_account IMPLEMENTATION.
METHOD withdraw.
IF me->amount > amount.
super->withdraw( amount ).
ELSE.
ENDIF.
ENDMETHOD.
ENDCLASS.
Special method
implementation
Special subclass
Call of general
implementation
SAP TechEd 03 Basel
ABAP Program
DATA: account1 TYPE REF TO account,
account2 TYPE REF TO account,
text TYPE string.
CREATE OBJECT: account1 TYPE checking_account
EXPORTING id = ...,
account2 TYPE savings_account
EXPORTING id = ...
TRY.
amnt = ...
account1->transfer( EXPORTING amount = amnt
target = account2 ).
ENDTRY.
Same object
reference
variables as
before
General
handles for
specialized
objects
Same usage of
objects as
before!
Polymorphism
Next Topic
Background
Encapsulation
Instantiation
Interfacing
Events
Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
SAP TechEd 03 Basel
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
SAP TechEd 03 Basel
Standalone Interfaces
CLASS cl_....
INTERFACES: if1,
if2.
...
ENDINTERFACE.
METHOD
if1~m1.
...
METHOD
if2~m2.
...
DATA:
oref1 TYPE REF TO if1,
oref2 TYPE REF TO if2.
oref2 oref1
INTERFACE if1.
METHODS: m1 ...
...
ENDINTERFACE.
INTERFACE if2.
METHODS: m2 ...
...
ENDINTERFACE.
Benefits of standalone interfaces:
Can be defined by client
Independency from implementation
Polymorphism
Separation of independent characteristics
SAP TechEd 03 Basel
Interfaces Example (1)
Class Pool
PUBLIC SECTION.
INTERFACES if_serializable_object.
...
ENDCLASS.
CLASS customer DEFINITION.
PUBLIC SECTION.
INTERFACES if_serializable_object.
...
ENDCLASS.
Class Pool
One interface in
different
classes
One interface in
different
classes
Interfaces Example (2)
ABAP Program
DATA: account TYPE REF TO account,
customer TYPE REF TO customer,
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.
APPEND: account TO serializable_objects,
customer TO serializable_objects.
...
LOOP AT serializable_objects INTO serializable_object.
CALL TRANSFORMATION id
SOURCE obj = serializable_object
RESULT XML xmlstr.
ENDLOOP.
Polymorphism
Interface
reference
variables
Instantiation of
classes
Collection of
references to
objects of
different classes
SAP TechEd 03 Basel
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
SAP TechEd 03 Basel
Events ABAP Objects (1)
Events are components of classes
METHOD...
...
RAISE EVENT evt
...
ENDMETHOD.
METHODS handler
FOR EVENT evt ...
METHOD handler
...
ENDMETHOD.
METHOD...
...
SET HANDLER
oref1->handler FOR oref2.
...
ENDMETHOD.
oref2
oref1
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
SAP TechEd 03 Basel
Events Example (1)
Class Pool
CLASS checking_account DEFINITION
PUBLIC SECTION.
METHODS deposit REDEFINITION.
...
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 ).
IF me->amount > limit.
RAISE EVENT consulting_required
EXPORTING amount = me->amount.
ENDIF.
ENDMETHOD.
ENDCLASS.
Allows the class to
publish an event
Announces a
state change
that requires an
action
Events Example (2)
Class Pool
CLASS consultant DEFINITION.
PUBLIC SECTION.
METHODS constructor.
...
PRIVATE SECTION.
...
METHODS receive_notification
FOR EVENT consulting_required OF checking_account.
ENDCLASS.
CLASS consultant IMPLEMENTATION.
METHOD constructor.
...
IF ...
SET HANDLER me->receive_notification FOR ALL INSTANCES.
ENDIF ...
ENDMETHOD.
...
METHOD receive_notification.
" do something
ENDMETHOD.
ENDCLASS.
Static subscription,
allows the class to
handle an event
Dynamic
subscription
Event handling
SAP TechEd 03 Basel
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 ...
ABAP Program
REPORT simple_report.
NODES spfli.
GET spfli.
WRITE: / spfli-carrid, spfli-connid ...
... who knows really whats happening here?
SAP TechEd 03 Basel
Simplicity ABAP/4 (2)
This is what happens after SUBMIT:
LOAD-OF-PROGRAM
Selection screen values are set
Program is loaded, start values are set
INITIALIZATION
Call of selection screen
AT SELECTION-SCREEN ...
START-OF-SELECTION
GET spfli
END-OF-SELECTION
Call of list processing for basic list
AT LINE-SELECTION, ...
Still simplified
scheme!
The exact program
flow depends on
different settings
In parallel,
subroutines of a
logical database
are implicitly
called!
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 objects interface
Programming with objects is more natural than
handling data via procedures
SAP TechEd 03 Basel
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
SAP TechEd 03 Basel
Explicitness Example (1)
Classes instead of logical data bases
Class Pool
CLASS ldb DEFINITION.
PUBLIC SECTION.
METHODS read_spfli.
EVENTS spfli_ready EXPORTING value(values) TYPE spfli.
PRIVATE SECTION.
DATA spfli_wa TYPE spfli.
ENDCLASS.
CLASS ldb IMPLEMENTATION.
METHOD read_spfli.
SELECT * FROM spfli
INTO spfli_wa.
RAISE EVENT spfli_ready EXPORTING values = spfli_wa.
ENDSELECT.
ENDMETHOD.
ENDCLASS.
Simple example for
a class that works
like a logical
database with a
single node
Explicit Interface
Events with parameters
Class instead of report program
ABAP Program
CLASS report DEFINITION.
PUBLIC SECTION.
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.
Simple example for
a class that works
like a report
Start via an OO
Transaction
Explicit event
handling
Decoupling of data
display from data
handling
SAP TechEd 03 Basel
ABAP Program
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( ).
ENDMETHOD.
METHOD get_spfli.
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.
Simplicity does not
necessarily mean
less coding
Next Topic
Background
Encapsulation
Instantiation
Interfacing
Events
Simplicity
Explicitness
Maintainability
Purified ABAP
Future Orientation
Conclusion
SAP TechEd 03 Basel
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
Function Group
FUNCTION f1.
PERFORM s1 ...
ENDFUNCTION.
FORM s1 ...
...
PERFORM f2 ...
...
ENDFORM.
FORM s2 ...
...
PERFORM s3
...
ENDFORM.
FORM s3 ...
...
ENDFORM.
Class Pool
PUBLIC SECTION.
METHODS: m1 ...
PRIVATE SECTION.
METHODS: m2 ...
m3 ...
ENDCLASS.
METHOD m1.
...
m2( ... ).
...
ENDMETHOD.
METHOD m2.
...
m3( ... ).
...
ENDMETHOD.
METHOD m3.
...
ENDMETHOD.
ENDCLASS.
Declaration
mandatory
Only methods
Navigation
No declaration
of procedures
Mixture of
different
procedures
SAP TechEd 03 Basel
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
SAP TechEd 03 Basel
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 , ...
ABAP/4
TABLES dbtab.
SELECT * FROM dbtab.
ABAP Objects
DATA wa TYPE dbtab.
SELECT * FROM dbtab INTO wa.
DATA BEGIN OF itab OCCURS 10.
...
CLEAR itab.
DATA itab TYPE TABLE OF ...
...
CLEAR itab.
Two data objects
with one name!
Inappropriate
short forms
Obsolete
declaration!
SAP TechEd 03 Basel
No implicit typing of field-symbols and formal
parameters
ABAP/4 ABAP Objects
FIELD-SYMBOLS <fs>.
IF <fs> IS ASSIGNED.
...
ENDIF.
Unexpected
behavior!
FIELD-SYMBOLS <fs> TYPE ANY.
...
ENDIF.
Expected
behavior!
No wrong data handling
ABAP/4 ABAP Objects
DATA number TYPE i VALUE ...
TRANSLATE number
TO UPPER CASE.
Undefined
behavior!
DATA number TYPE i VALUE ...
TRANSLATE number
TO UPPER CASE.
Syntax error
SAP TechEd 03 Basel
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,
col1(4) TYPE c,
col2 TYPE i,
END OF struc2.
struc2 = struc1.
ABCD ####
struc2 in non-Unicode-enabled ABAP:
Code page
dependent
representation of
blanks
ABCD 0
struc2 in Unicode-enabled ABAP:
Type specific
SAP TechEd 03 Basel
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.
off = sy-index - 1.
ASSIGN text1+off(1) TO <fs>.
<fs> = 'X'.
ENDIF.
ENDDO.
XXXXXFGHIJ
text2 in non-Unicode-enabled ABAP:
Memory
overwriting,
even for
references!
ABCDEFGHIJ
text2 in Unicode-enabled ABAP:
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
SAP TechEd 03 Basel
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
R/2 ABAP ABAP/4 ABAP Objects Unicode enabled
Dont get
lost!
Possible future
developments
Migration
SAP TechEd 03 Basel
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
SAP TechEd 03 Basel
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
SAP TechEd 03 Basel
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
SAP TechEd 03 Basel
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 Group
FUNCTION-POOL flight_screens.
SELECTION-SCREEN BEGIN OF SCREEN 100 AS WINDOW.
PARAMETERS: p_carrid TYPE sflight-carrid,
p_connid TYPE sflight-connid,
p_fldate TYPE sflight-fldate.
SELECTION-SCREEN END OF SCREEN 100.
TABLES sflight.
Selection
Screen
FUNCTION get_flight_parameters.
CALL SELECTION-SCREEN 100 STARTING AT 10 10.
... " checks
carrid = p_carrid.
connid = p_connid.
fldate = p_fldate.
ENDFUNCTION.
Interface
data for
dynpro
FUNCTION get_plane_type.
sflight-planetype = plane_type.
... " preparation
CALL SCREEN 200 STARTING AT 10 10.
... " checks
plane_type = sflight-planetype.
ENDFUNCTION.
Screen
handling in
function
modules
Screen
handling in
function
modules
Further step:
Local classes in
function group as
screen handlers
SAP TechEd 03 Basel
Appendix C Encapsulation of Screens (2)
Object driven usage of screens
Class Pool
CLASS flights DEFINITION.
PUBLIC SECTION.
METHODS: constructor,
change_plane_type.
PRIVATE SECTION.
DATA flight TYPE sflight.
ENDCLASS.
CLASS flights IMPLEMENTATION.
METHOD constructor.
DATA: carrid TYPE sflight-carrid,
connid TYPE sflight-connid,
fldate TYPE sflight-fldate.
CALL FUNCTION 'GET_FLIGHT_PARAMETERS'
IMPORTING
carrid = carrid
connid = connid
fldate = fldate.
SELECT SINGLE *
FROM sflight
INTO flight
WHERE carrid = carrid AND
connid = connid AND
fldate = fldate.
ENDMETHOD.
METHOD change_plane_type.
CALL FUNCTION 'GET_PLANE_TYPE'
CHANGING
plane_type = flight-planetype.
ENDMETHOD.
ENDCLASS.
Call of
functions with
parameters
Call of
functions with
parameters
Further Information
ABAP Documentation:
Always the first source of information
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)
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 TechEd 03 Basel
Q&A
Questions?
Please complete your session evaluation and
drop it in the box on your way out.
Feedback
Thank You !
The SAP TechEd 03 Basel Team
SAP TechEd 03 Basel
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 Server
TM
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.
Copyright 2003 SAP AG. All Rights Reserved

Why Use ABAP Object by Horst Keller

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Why Use ABAP Object by Horst Keller

Încărcat de

Drepturi de autor:

Formate disponibile

SAP TechEd 03 Basel

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

SAP Press Books:

and SQL Server

are registered trademarks of

, DB2 Universal Database, OS/2

, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere

is a registered trademark of ORACLE Corporation.

are registered trademarks of the Open Group.

, the Citrix logo, ICA

, World Wide Web Consortium,

is a registered trademark of Sun Microsystems, Inc.

S-ar putea să vă placă și