Experience in ABAP OO and heavy background processing?

[Former Member]

Hi,

we're planning to develop a new application with a (very) high part of background processing. We plan to use the ABAP OO. We also want to make a good OO-Design (with many SETTER and GETTER methods and so on). I'm afraid we will get a lot of "program to program" communication and we will atomize our application. Also it's sounds to me like a conflict with the stuff from the Performance-course BC490.

Has anybody experience with ABAP 00 and applications that normally designed for a "number cruncher"?

Thanks and regards,

Stefan

[former_member183804]

Hello Stefan,

getter() and setter() methods offer a great opportunity for extensible frameworks or API´s. But since in ABAP OO instantiation and method invocation is not granted for free one should be very careful not to use them without need.

ABAP is a hybrid language and offers both OO and a rich type world. Especially entities of mass data should not be designed to be instances. Stick to internal tables there and you will save plenty of time.

An OO API as encasulation to an internal table may also be useful. Combined with an iterator/cursor or index based access this offers another approach (but still only if an API is required).

gards

Klaus

[Former Member]

Hi Klaus,

thanks for your approach. It sounds very interesting but I'm not sure that I understood your solution:

- Use an internal table as a static attribut of the class and load all needed attributes from the database at moment of the jobstart.

- The constructor doesn't load the data from the database into the attributes of the object when the object-instance is created. Only the index is acquired.

- the GETTER (and other methods) access to the internal table by the index from the constructor.

Is this correct?

I will test this after my easter-holiday and will post the results.

Thanks,

Stefan

[former_member183804]

Hello Stefan,

my intention was more a private attribute ( regardless whether static or instance). For example something like:

class lcl_Tadir definition.
  public section.
    methods:
      constructor importing Entries type standard table of Tadir,
      set_Cursor importing Index,
      add_Entry  importing Entry type Tadir,
      get_Author returning value(Result) type Tadir-Author,
      get_Entries returning value(Result) type standard table of Tadir with default key.
  private section.
    data:
      f_Entries type standard table of Tadir with default key,
      f_Cursor  type i.
endclass.

Whereas I would NOT use this approach without need for extensibility.

Kind Regards

Klaus

[Former Member]

Dear Stefan,

I´m very interested in the results of your tests. I´m starting with the design of an OO application and there´s always the fear of having bad performance because of the lack of knowlegde of this techonology.

For example, how to pass vectors from one object to another.. as a table or encapsulated as an object?

And of course as you mentioned, how to deal with I/O?

By the way, has any of you tried persistent objects??

[Former Member]

Hi Mariana,

I've started with two technical prototypes that have a very little business logic. One prototype is designed in the "good old" ABAP and one in the ABAP OO and a selfmade OO-framework from our company. This framework is very comforable and offers a lot of methods and superclasses. For vectors there is a own superclass. So for you question: We use a own object to pass the vectors.

Also we use the software objectif for the OOD. I've learned how important a good OOD is, before I started any coding.

My prototypes have a very simple business logic. They creates bills for 10.000 invoice recipient. The only feature is, that every recipient can have his own customizing to decide which items should be together on one invoice to a individual invoice date.

I must admit that the API in the OO prototype are more understandable, but for the performance I see still the follow bottlenecks with the I/O:

- When I instance a business object, all attributs are loaded into the memory. In the old ABAP I use only the required fields. So the "smelly" SELECT *-Statement is back again...

- A business-class (A) that have dependent business-classes (B1, B2, B3...BN) should instance his dependes objects with the first access the the class (A). When the classes (B1,B2...BN) has also dependent classes, this object should be instances (B1 has C1,C2,C3..CN), too. There is always a "vector"-class between this classes that notice the reference of his objects.In my prototype for example you have a invoice recipient.

In my prototype for example I have a class invoice recipient (class A). This recipient has a vector of bill-header (class B) and every bill-header has a vector of bill-items (class C). Between every of this classe is a vector-class that manage the references of the objects.

I've programmed this lazy (hope that this is the correct word that a OO-gurus use). This means I instance only the class A. If there is a call to a method from object A that need the information from the class B-objects, than i look if the reference of the vector-class for the B-Object is already available. When not I instance the vecotr-class and this reads all dependens object B.

So there is much more I/O than in old ABAP, after all.

However I'm a OO beginner.

Therefore I'm waiting that an OO-expert from our company take a look to my prototype coding and improve this for a better performance. I'm looking forward for some good tips. I will let you know when I've good some other nuts and bolts.

Perhaps SAP needs a OO-database instead a rational database, so that all GET-methods goes directly to the database to avoid a instance with all attributs in the memory of the application-server...

Many greetings from germany,

Stefan

[Former Member]

My experience is that all Business oriented performance issues revolve around I/O. Unless you are doing something like weather forecasting, all of your performance concerns will be minimizing the number of data base calls and maximizing the return from each database call.

I suggest you celebrate the fact that you get some ABAP OO experience and concentrate on the design while keeping in mind the performance issues with I/O.

Let us know how it goes.

[Former Member]

Hi Charles,

thanks for your suggestion. I've decided to make two prototypes with a little business functionaliy.

I'm going to programm the first in the old classic ABAP and the second in ABAP OO.

The prototypes will be process successive a couple of thousand transaction. So it's should be also a challenge for the gabarage collector.

I will post my experience after my holiday.

Regards,

Stefan