ABAP-Programme weiterentwickeln

Feature | 27. Oktober 2003 von admin 0

Prozedurales Programmieren stößt bei komplexen Aufgabenstellungen an Grenzen. Sollen beispielsweise bei der SAP-R/3-Komponente für den Vertrieb (SD, Sales & Distribution) in einer Funktionsgruppe beziehungsweise einem Funktionsbaustein nicht nur ein einziger SD-Beleg, sondern gleich mehrere im Arbeitsspeicher gehalten werden, dann bekommt ein Programmierer in ABAP alle Hände voll zu tun. Er muss die Schnittstelle des Funktionsbausteins ändern, muss die Daten in neuen internen Tabellen vorhalten und muss alle Programme, die diesen Funktionsbaustein verwenden, anpassen und testen. Dies ist umständlich, nur mit viel Zeitaufwand zu meistern und fehleranfällig. Außerdem wird das Programm zu Lasten der Antwortzeiten aufgebläht.

Daten und Funktionen vereint

Anders beim objektorientierten Ansatz. Hier lassen sich auf einfache Weise beliebig viele neue Objekte erzeugen. Beim objektorientierten Programmieren sind Daten und die dazu gehörigen Operationen, Funktionen oder Prozeduren nicht mehr wie beim prozeduralen Programmieren voneinander getrennt, sondern gemeinsam in Objekten gekapselt. Abläufe lassen sich realitätsnah umsetzen. Der verkapselte Informationskern eines Objektes bleibt jedoch vor ungewollten Eingriffen von außen geschützt. Jedes Objekt ist für die eigenen Daten gewissermaßen selbst zuständig. Die Kapselung bewirkt zudem eine bessere Strukturierbarkeit und Durchgängigkeit im Prozess der Softwareentwicklung. Im Gegensatz zur Funktionsgruppe, die lediglich ein Mal im Hauptspeicher stehen kann, können Objekte also beliebig oft im Hauptspeicher platziert sein. Deshalb ist keinerlei Programmieraufwand nötig, wenn – um beim Beispiel zu bleiben – statt nur eines SD-Belegs plötzlich mehrere erforderlich sind.

Gegenseitig kompatibel

Die von SAP verfolgten Design-Ziele bei ABAP Objects waren Einfachheit sowie die Verwendung objektorientierter Konzepte, die sich bewährt haben. Der Entwicklungsaufwand für in ABAP oder ABAP Objects geschriebene Programme ist etwa gleich. In ABAP Objects erstellte Hauptprogramme sind aufgrund ihrer Objektstruktur generell weniger umfangreich und dadurch vor allem leichter zu warten. Im Hauptprogramm selbst befinden sich im äußersten Fall beinahe nur noch die Adressen von den Objekten, so genannte Referenz-Zeiger oder Pointer. Das eigentliche Programm ist über die Objekte programmiert. Es bleibt zu beachten, dass SAP R/3 nicht durchgängig in ABAP Objects programmiert ist. So lassen sich etwa Bildschirmmasken nur prozedural programmieren, aber innerhalb der Masken sind Befehle in ABAP Objects verwendbar. ABAP Objects, als echte, kompatible Erweiterung von ABAP, bedient sich klassischer ABAP-Anweisungen, genau wie sich Objects-Anweisungen auch in prozeduralen Programmen verwenden lassen.

Beispiel SD-Beleg

Eine besondere Eigenschaft objektorientierter Programmiersprachen ist das Prinzip der so genannten Vererbung (Inheritance). Methoden und Attribute (Funktionen und Daten) lassen sich an Unterklassen vererben, dort aber spezifisch ausprägen. Die Klasse bildet gewissermaßen “den kleinsten gemeinsamen Nenner”, während die Unterklassen die Unterschiede von der Regel enthalten. Zurück zum Beispiel: SD-Belege wie “Angebot”, “Auftrag”, “Lieferschein” haben vieles gemeinsam. Sie lassen sich anlegen, ändern, löschen, drucken. Also bietet sich für diese Aufgabenstellungen eine allgemeine Klasse “SD-Beleg” an. “Auftrag”, “Angebot” und “Lieferschein” erben von dieser Klasse alle Attribute und Methoden und sind ohne weitere Programmierung anzuwenden. Nun zu den Unterschieden: Nur über den Lieferschein ist es möglich, Ware auszuliefern. Die Methode – also Funktion – “Ausliefern” muss für “Lieferschein” neu hinzugefügt werden. Da die Klasse “SD-Beleg” die Methode “Ausliefern” nicht kennt, kennen auch “Angebot” und “Auftrag” diese Methode nicht. Nur das von der Klasse Abweichende ist zu programmieren (Programming by Difference). Dadurch wird der Aufwand deutlich reduziert und der Forderung nach leicht erweiterbaren Programmkomponenten für die Softwareentwicklung Rechnung getragen.
Darüber hinaus haben “Angebot”, “Auftrag” und “Lieferschein” unter anderem unterschiedliche Ausgaben beim Druck. Deshalb muss bei der Methode “Druck” für das “Angebot” ein anderes Coding als beim “Lieferschein” ablaufen. Auch hier unterstützt ABAP Objects den Programmierer. Über das Redefinieren von Methoden, ist eine klassenspezifische Verarbeitung anzugeben. Weil zudem das Coding an dem Objekt “klebt”, braucht sich der Programmierer beim Aufruf der Methode “Druck” eines beliebigen Objekts der Klasse “SD-Beleg” oder deren Erben nicht darum zu kümmern, dass das korrekte Coding abläuft. Diese Eigenschaft wird fachsprachlich als Polymorphie (Vielgestaltigkeit) bezeichnet.

BAdIs ersetzen User Exits

SAP R/3 ist eine Standard-Software. Dennoch bietet das SAP-Produkt die Möglichkeit, Anpassungen vorzunehmen. Was beispielsweise, wenn ein Kunde wünscht, den aktuellen Lagerbestand eines Artikels im Auftrag zu sehen? Die unpraktikabelste Lösung wäre es, den Standard zu modifizieren. Mit jedem Supportpackage von SAP hätte in diesem Fall der System-Administrator des Kunden neue Arbeit: Immer und immer wieder müsste er dafür sorgen, dass die eigenen Änderungen in dem neuen Programm enthalten sind.
Um dieses Problem zu vermeiden, hat SAP User Exits zur Verfügung gestellt. User Exits sind fixe Punkte im Programm mit einer definierten Schnittstelle. Sie sind nur dafür da, dass der Anwender an bestimmten Stellen im Programm eigene Funktionen aufrufen kann – beispielsweise also den aktuellen Lagerbestand. Der Platz am User Exit ist jedoch begrenzt. Wenn er schon mit einer Funktion belegt ist, lassen sich weitere nur nachrangig anhängen. Dies ist vor allem bei Add-Ons und Länderanpassungen problematisch. Sie belegen den Platz, der eigentlich für Kundenanpassungen vorgesehen ist. Hier helfen neuerdings die Business Add-Ins (BAdIs). Business Add-Ins sind über ABAP Objects realisiert und bieten die Möglichkeit, mehrfach (also Länderanpassung, IBU, Add-On und Kunde) die gleiche Stelle zu nutzen, ohne sich gegenseitig zu behindern. Partnerlösungen für die mySAP Business Suite enthalten vorwiegend BAdIs.
Die bewährte prozedurale Programmiersprache ABAP hat nach wie vor ihre Berechtigung. ABAP Objects ist jedoch die logische Weiterentwicklung. Denn durch konsequentes Anwenden des objektorientierten Ansatzes lassen sich Programme einfacher warten und erweitern, Teilkomponenten leichter wiederverwenden und die Teilaufgaben großer Programmier-Projekte besser abgrenzen. Das Hauptprinzip der Objektorientierung ist eine ganzheitliche Sichtweise auf die Daten und Funktionen der abzubildenden realen Objekte.

Johannes Öhl

Johannes Öhl

1 comment

  1. Robert

    Einen schönen guten Abend.

    Ich sah Ihre Page und habe ein Problem.

    Vielleicht können Sie mir dabei helfen.

    Situation:

    Ein instanziertes Objekt soll auf mitbekommen, dass ein RFC Baustein von aussen aufgerufen wurde.

    Umfeld:

    Ein Objekt wird erzeugt und liegt in seinem Prozess im Speicher.

    Eine Externe Anwendung ruft einen RFC-Baustein auf. Dieser Aufruf soll dem Objekt “mitgeteilt” werden, wenn möglich , mit Übergabe von Parametern.

    Idee bisher:

    Das Objekt hat ein Klassenattribut, ref to myclass. Das Objekt hat eine Methode, die als Ereignisbhandler definiert ist, und zwar für ein Ereigniss der Klasse myclass. Im Constructor instanziiere ich dieses Attribut zu einer Referenzt auf myclass-Objekt. Weiterhin registriere ich diesen Handler.

    So.

    Nun aber bin ich, wenn der FuBa aufgerufen wird, in einem anderen Prozess , oder Thread.
    Ich denke, ich müsste die Referenz in der Hauptklasse exportieren, im Fuba Importieren, und dann das ereigniss feuern, in der Hoffnung, dass über die Prozessgrenzen hinweg der Handler in der Hauptklasse anspringt.
    Nur kann man Referenzen nicht exportieren.
    Wissen Sie, wie ich da vorgehen könnte?

    VIelen Dank.

    Grüsse

    Robert

Leave a Reply