Skip to Content
author's profile photo Former Member
Former Member

moving from ABAP to ABAP oo

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 :



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 ?

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Oct 13, 2005 at 08:24 AM

    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.



    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      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.



Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.