moving from ABAP to ABAP oo

[Former Member]

We are currently running on a 4.0 system, but are preparing for an upgrade to ERP '05.

I have looked at OO and have collected a few questions.

1. A simple ABAP report today in 4.0 looks like this :

Selection-screen

Start-of-selection

Perform read_data

Perform manipulate_data

Perform write_data

As you can see no data is passed between calls using EXPORT/IMPORT…..

If this report had to be re-written in OO is it best practise to pass data/internal tables to the methods – encapsulate ?

2. I have several times heard that screen/dynpro processing should be isolated in Functionsmodules (when not using WEB Dynpros)

We are having approx 30 RF application (running on radio frequency terminals with 10X20 character based scrrens).

How should the screens be isolated ? One FM pr. Screen ? And what about selection-screens – should only the selection screen be isolated returning the parameters/select-options or should such a FM also read the data based on the selection criteria’s ?

[former_member225448]

Hi Kim,

add 1:

Leave your reports as they are. ABAPoo is an extension of the ABAP Language and not an replacement. ABAPoo has been designed, because some dev. areas are better handled by an object oriented approach, e.g. graphical UI's.

add 2:

Classes in ABAPoo are technically are not having any global fields. Static attributes are the same concept, but technically handled differently.

If you like see a field on a Dynpro, this field has to be a global field of the Dynpro's Modulepool. As ABAPoo classes do not have such global fields, you have to create a Functionpool to hold this screen work area.

But again as in your 1st question: if you your programs work well today, there is a 99% chance that they also run on a 6.40 kernel. There are some restriction with Unicode, but that can be handled by minor changes and does not force a complete redesing.

If you find my answer useful, please don't forget the reward.

Regards,

Juergen

[Former Member]

If isolation dynpros in a module pool - to split businees logic from screen handling I still need some good advice/examples on what to put in the module pool/or FM and what to put in the calling program.

Upgrading from 4.0B to ECC 5.0 with IS-CWM will without doubt resulting in a lot of programs not running.

[former_member225448]

Hello Kim,

you will face a lot of UNICODE errors in such an upgrade, because in an UNICODE system, structured fields will no longer be treated as type C fields.

You will have syntax errors because of code like:

TABLES mara.
mara+17(4) = '1234'.

But the system will not say: "Program has no object oriented design". That's the point, you will have new features, but you won't loose to old ones, except from some incompabilities, like the one described above.

Regards,

Juergen