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 BreschABAP 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 generalExplain the benefits of ABAP Objects compared to classical ABAPUnderstand why Unicode enabled ABAP Objects is the best language for business applications up to now




Agenda

Background

Principal Features of ABAP ObjectsEncapsulationInstantiationReuse via InheritanceInterfacingEvents

Benefits of ABAP ObjectsSimplicityExplicitnessMaintainabilityPurified ABAPFuture Orientation

Conclusion


Next Topic

Background



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 [email protected])


Background – ABAP and ABAP Objects at the WAS

Persistent Data(Database, Files, ...)

User Interface(SAP GUI, Web, ...)

WebApplicationServer

...SELECT * FROM ......

ABAP

ABAP Objects




Background – Object Orientation in ABAP

Pure Object Oriented ABAPWorld ?

ABAP Non-ABAP

Technically possible!



ABAP

ObjectswithApplicationLogic





ABAP

Persistence andTransaction Services provided byObject Services,as ofRelease 6.10



ABAP

GUI ControlFramework,OfficeIntegration,BusinessServerPages,etc.





ABAP Non-ABAP

For example JavaScript(as of Release 6.10)



SystemClassesfromLibraries

ApplicationCodingis here!





Purified ABAP

Inside Objects?

METHOD...DATA ... TYPE ......LOOP AT itab

REFERENCE INTO ......

ENDMETHOD.



Reality ...

ABAP + ABAP Objects

ABAP Non-ABAP

CALLFUNCTIONDESTINATION...

CALLSCREEN...

SELECT ...




Next Topic

Background



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




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





Function Group

FUNCTION-POOL account.

DATA account_tab TYPE SORTED TABLE OF accountsWITH 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'EXPORTINGid = id_fromamount = amount.

CALL FUNCTION 'DEPOSIT'EXPORTINGid = id_toamount = amount.

ENDFUNCTION.

FUNCTION withdraw.DATA account_wa TYPE accounts.READ TABLE account_tab INTO account_wa

WITH TABLE KEY id = id.IF account_wa-amount > amount.account_wa-amount = account_wa-amount - amount.MODIFY TABLE account_tab FROM account_wa.


ENDIF.ENDFUNCTION.

Data identified by

input parameters

Data identified by

input parameters




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.

CLASS ... DEFINITION.PUBLIC SECTION.

METHODS ...PRIVATE SECTION.

DATA ......

ENDMETHOD.ENDCLASS.

CLASS ... IMPLEMENTATION.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 accountRAISING 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




Encapsulation – Example ABAP Objects (2)

Class Pool

CLASS account IMPLEMENTATION.METHOD constructor.SELECT SINGLE amount

FROM accountsINTO (amount)WHERE id = id.

ENDMETHOD.METHOD deposit.me->amount = me->amount + amount.

ENDMETHOD.METHOD withdraw.IF me->amount > amount.me->amount = me->amount - amount.


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



Conclusion




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 expliciteinstantiation, 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'EXPORTINGid_from = id1id_to = id2amount = 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




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

oref1oref2

Many instances of

one class


Instantiation – Example ABAP Objects

ABAP Program

DATA: account1 TYPE REF TO account,account2 TYPE REF TO account,amnt TYPE p DECIMALS 2,exc_ref TYPE REF TO cx_negative_amount,text TYPE string.

CREATE OBJECT: account1 EXPORTING id = ...,account2 EXPORTING id = ...

TRY.amnt = ...account1->transfer( EXPORTING amount = amnt

target = account2 ).CATCH cx_negative_amount INTO exc_ref.text = exc_ref->get_text( ).MESSAGE text TYPE 'I'.

ENDTRY.

Object reference

variables as explicit handles

Independent objects based on the same

class

Static type check

Natural working with

instances




Next Topic

Background



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 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 accountPERFORM withdraw_from_checking_account USING id amount.

WHEN 'S'. "Savings accountPERFORM 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_accountUSING l_id TYPE accounts-id

l_amount TYPE accounts-amount.DATA account_wa TYPE accounts.READ TABLE account_tab INTO account_wa WITH TABLE KEY id = l_id.account_wa-amount = account_wa-amount - l_amount.MODIFY TABLE account_tab FROM account_wa.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-amountRAISING cx_negative_amount.

DATA account_wa TYPE accounts.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.MODIFY TABLE account_tab FROM account_wa.


ENDIF.ENDFORM.

Specialized procedures,

no code reuse

Specialized procedures,

no code reuse




Reuse – ABAP Objects

Reuse of general classes

Specialization via inheritance

BenefitsSmall classes

Minimal parameter interfaces

Polymorphism (CASE-less programming)

enhanced Modeling capabilities


Reuse – Example ABAP Objects (1)

Class Pool

CLASS account DEFINITION.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





Class Pool

CLASS checking_account DEFINITIONINHERITING 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 DEFINITIONINHERITING FROM account.

PUBLIC SECTION.METHODS withdraw REDEFINITION.

ENDCLASS.Method

redefinition

CLASS savings_account IMPLEMENTATION.METHOD withdraw.IF me->amount > amount.super->withdraw( amount ).


ENDIF.ENDMETHOD.

ENDCLASS.

Special method implementation

Special subclass

Call of general implementation





ABAP Program

DATA: account1 TYPE REF TO account,account2 TYPE REF TO account,amnt TYPE p DECIMALS 2,exc_ref TYPE REF TO cx_negative_amount,text TYPE string.

CREATE OBJECT: account1 TYPE checking_accountEXPORTING id = ...,

account2 TYPE savings_accountEXPORTING id = ...

TRY.amnt = ...account1->transfer( EXPORTING amount = amnt

target = account2 ).CATCH cx_negative_amount INTO exc_ref.text = exc_ref->get_text( ).MESSAGE text TYPE 'I'.

ENDTRY.

Same object reference

variables as before

General handles for specialized

objects

Same usage of objects as

before!

Polymorphism


Next Topic

Background



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

CLASS cl_....INTERFACES: if1,

if2....

ENDINTERFACE. METHODif1~m1. ... METHODif2~m2....

DATA:oref1 TYPE REF TO if1,oref2 TYPE REF TO if2.

oref2oref1

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




Interfaces – Example (1)

Class Pool

CLASS account DEFINITION.PUBLIC SECTION.INTERFACES if_serializable_object....

ENDCLASS.

CLASS customer DEFINITION.PUBLIC SECTION.INTERFACES if_serializable_object....

ENDCLASS.

Class PoolOne 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_objectRESULT XML xmlstr.

ENDLOOP.

Polymorphism

Interface reference variables

Instantiation of classes

Collection of references to

objects of different classes




Next Topic

Background



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......RAISE EVENT evt...

ENDMETHOD.

METHODS handler FOR EVENT evt ...

METHOD handler...

ENDMETHOD.

METHOD......SET HANDLER

oref1->handler FOR oref2. ...

ENDMETHOD.

oref2oref1


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 Pool

CLASS checking_account DEFINITIONINHERITING FROM account.

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




Next Topic

Background



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 what’s happening here?




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 object’s interface

Programming with objects is more natural than handling data via procedures




Next Topic

Background



Conclusion


Explicitness

ABAP/4 has many implicit features, e.g.: Implicit interfaces via global data

Dynpros

Logical Databases

Programs are controlled by runtime environmentPrograms are driven from Dynpros

Program execution via SUBMIT

ABAP Objects is explicitno hidden concepts

no “black magic”




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





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



Conclusion




Maintainability

Programs using ABAP Objects areeasier 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

CLASS ... DEFINITION.PUBLIC SECTION.METHODS: m1 ...

PRIVATE SECTION.METHODS: m2 ...

m3 ...ENDCLASS.

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




Next Topic

Background



Conclusion


Purified ABAP - Syntax (1)

ABAP/4 has developed over a long period of timelarge number of obsolete statements overlapping conceptshighly specialized conceptssurprising implicit behaviordifficult to learn




Purified ABAP - Syntax (2)

ABAP Objects reduces the complexity of ABAPmany obsolete statements and additions are forbiddenmany implicit syntax completions must be done explicitwrong handling of data is restricted


Purified ABAP – Syntax Examples (1)

Clean-Up in ABAP ObjectsNo 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!

Inappropriateshort forms

Obsolete declaration!





Clean-Up in ABAP ObjectsNo 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.

IF <fs> IS ASSIGNED....

ENDIF.

Expected behavior!



Clean-Up in ABAP ObjectsNo 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




Purified ABAP - Semantics

Unicode-enabled ABAPStatic type checks specified more preciselyByte and character strings processed separatelyStructures handled appropriately for their type using structural equivalence rulesUncontrolled memory manipulation no longer permitted


Purified Semantics – Example (1)

Unicode-enabled ABAPStructures 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 0struc2 in Unicode-enabled ABAP:

Type specific




Purified Semantics – Example (2)

Unicode-enabled ABAPNo access to memory outside a data objectDATA: 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>.IF <fs> IS ASSIGNED.<fs> = 'X'.

ENDIF.ENDDO.

XXXXXFGHIJ text2 in non-Unicode-enabled ABAP:

Memoryoverwriting,

even for references!

ABCDEFGHIJtext2 in Unicode-enabled ABAP:

Memory protection


Purified Syntax + Purified Semantics

Unicode-enabled ABAP Objects!Unicode-enabled ABAP Objects is the best ABAPavailable up to now!If you use Unicode-enabled ABAP Objects, you program automatically according to the rules of purified syntax and semanticsEven if you do not exploit the real “object oriented”features, programs written in Unicode-enabled ABAP Objects are

more robustless error pronebetter to maintain




Next Topic

Background



Conclusion


Future Orientation

(Unicode enabled) ABAP Objects is part of an ongoing evolution

R/2 ABAP ABAP/4 ABAP Objects Unicode enabled

Don‘t get lost!

Possible futuredevelopments

Migration




Next Topic

Background



Conclusion


Conclusion - Summary

ABAP Objects offersbetter encapsulationbetter interfacesbetter techniques for reusemore static type securitysupport for multiple instantiationbetter support for dynamic programming




Conclusion - Recommendation

Everybody programming in ABAP should use ABAP Objects for new and ongoing projects

take advantage of object oriented featuresuse methods as far as possible, even if you stay within the procedural programming modeldo not use subroutines any moreuse 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 literalsDeclarations: 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 permittedForbidden 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 objectsField symbols: No implicit types; FIELD-SYMBOLS … STRUCTURE, ASSIGN ... TYPE, ASSIGN LOCAL COPY OF, ASSIGN TABLE FIELD not permittedLogic expressions: ><, =<, => not permitted, table used with INmust be a selection tableControl 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 permittedProcedures (methods): No implicit type assignment, compatibleinitial values only, passing sy-subrc not permitted, raising undefined exceptions not permittedProgram calls: No joint use of USING and SKIP FIRST SCREEN when calling transactions, passing formal parameters implicitly in CALL DIALOG not permittedDatabase accesses: No implicit work areas, no *-work areas, READ, LOOP, REFRESH FROM on database tables not permitted, VERSIONaddition to DELETE and MODIFY not permitted, no PERFORMING additionin Native SQLData cluster: No implicit identifiers, passing parameters explicitly not permitted, no implicit work areas, MAJOR-ID and MINOR-ID not permittedLists: DETAIL, SUMMARY, INPUT, MAXIMUM, MINIMUM, SUMMING, MARK, NEW-SECTION and obsolete print parameters not permitted




Appendix B – Stricter Syntax in Unicode ProgramsOffset/length accesses: Only performed on character-type or byte-type ranges, and only on flat character-type initial parts of structuresMemory accesses: No access to memory outside a data objectSeparation 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 componentsStructures: When assigning and comparing you must take the Unicode fragment view into considerationFile interface: Implicitly opening files not permitted; access, storage, and coding type must be specified explicitly; no write access to read-only filesConversions: TRANSLATE ... CODE PAGE ..., TRANSLATE ... NUMBER

FORMAT ... not permittedOPEN SQL: Stricter conditions for work areasType 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.... " checkscarrid = p_carrid.connid = p_connid.fldate = p_fldate.

ENDFUNCTION.

Interface data for dynpro

FUNCTION get_plane_type.sflight-planetype = plane_type.... " preparationCALL 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




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'IMPORTINGcarrid = carridconnid = connidfldate = fldate.

SELECT SINGLE *FROM sflightINTO flightWHERE carrid = carrid AND

connid = connid ANDfldate = fldate.

ENDMETHOD.METHOD change_plane_type.CALL FUNCTION 'GET_PLANE_TYPE'CHANGINGplane_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




Q&A

Questions?


Please complete your session evaluation anddrop it in the box on your way out.

Feedback

Thank You !

The SAP TechEd ’03 Basel Team




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.

Copyright 2003 SAP AG. All Rights Reserved

why use abap object by horst keller

Documents

sap ag sap ag

sap ag abap

basel abap256

background abap

abap program

classical abap

use abap objectshorst

sap basis release