SAP-Programme erweitern

In diesem Artikel beschreibe ich die Möglichkeiten für eine Erweiterung eines Standardprogramm und mein Vorgehen bei der Erweiterung von SAP-Software. Das betrifft die logistischen ABAP-Programme und Transaktionen im SAP-NetWeaver.

Im SAP gibt es verschiedene Möglichkeiten, um die Programme zu erweitern. Die hier beschriebenen sind vor allem in den logistischen Modulen zu finden.

  1. User-Exit als Form: Das sind einfache Form-Routinen in Programmen, die im Namen den Begriff userexit enthalten. Sie sind von der SAP für Kundenanpassungen entworfen, sodass die Programmstellen häufig ganz gut verwendet werden können. Um sie zu implementieren wird der Include, der das Form enthält entweder per Modifikationsschlüssel (SSCR-Schlüssel im SAP-Marktplatz erhältlich) freigeschaltet oder man kann implizite Enhancementimplementierungen anlegen. Dazu später mehr.
  2. User-Exit als Funktionsbaustein: Sie sind in der Transaktion SMOD aufgeführt und mit der Transaktion CMOD können Kundenprojekte angelegt und aktiviert werden. In den eigentlichen Funktionsbausteinen befindet sich ein Include, der angelegt werden muss. In den SAP-Programmen sind sie am Aufruf „call customer-function“ gefolgt von einer Zahl zu erkennen.
  3. BADI: Das ist die objektorientierte Version der User-Exits. Hier sind genau wie bei den anderen User-Exits konkrete Punkte von der SAP ausgewählt und mit einer Schnittstelle versehen. Die Technik basiert auf Interfaces und Klassen, die die Interfaces implementieren. Je nach Programmstelle kann ein BADI mehrfach für verschiedene Implementierungen ausgeprägt werden. Es kann allerdings auch vorkommen, dass ein BADI als SAP-intern markiert wurde und somit nicht für Kundenimplementierungen zur Verfügung steht. Mit der Transaktion SE19 können Implementierungen angelegt und erstellt werden. Bei der Anlage wird eine BADI-Implementierung für die Konfiguration und eine Klasse für den eigentlichen Code erzeugt. Sie sind in das Enhancement-Framework eingebunden, sodass zusätzlich eine Enhancementimplementierung erstellt werden muss, die das BADI enthält.
  4. Enhancements: Sie sind die neueste Form der Erweiterungen. Sie haben keine eigene Datenschnittstelle und in ihnen kann man genau wie mit den Form-User-Exits auf alle Daten des Rahmenprogramms zugreifen. Es gibt eine implizite und eine explizite Version der Enhancements. Die implizite Version ist immer am Anfang und am Ende von Programmen, Includes, Funktionen, Methoden oder Form-Routinen vorhanden. Sie müssen nur über das Menü eingeblendet werden und sind ansonsten immer in allen Programmen vorhanden. Daneben gibt es explizite Enhancement-Points. Sie sind von der SAP an sehr vielen Programmstellen eingebaut. Sie befinden sich innerhalb von Programmroutinen oder Datendefinitionen. Enhancements sind überall vorhanden und leicht zu verwenden, aber gleichzeitig ist es nicht einfach eine geeignete Stelle zu finden. Bei den vorherigen Techniken hat sich jemand schon eine geeignete Programmstelle überlegt und sie für Kundenimplementierungen vorgesehen. Bei den Enhancements muss sich der Entwickler diese Stelle selber aus dem gesamten zu erweiternden Programm heraussuchen. Das kann durchaus zu einer längeren Suche per Debugging oder Code-Analyse führen. Wenn man das Programm im Editor geöffnet hat, kann man den Editormodus mit dem Spiralbutton in der Menüleiste auf den Erweiterungsmodus umschalten und anschließend lässt per Rechtsklick auf die Stelle oder über das Menü eine Implementierung erstellen. Sie können danach über die Transkation SE19 aufgerufen werden.
  5. Modifikation: Das ist eigentlich keine richtige Erweiterungstechnik. Hier holt man sich aus dem SAP-Marktplatz einen Zugangsschlüssel zum Programm (SSCR-Schlüssel) und ändert den Quellcode um. Dazu muss allerdings per Button eine Modifikation eingefügt werden, sodass die Stellen immer deutlich gekennzeichnet sind. Genau wie bei den Enhancements steht der Entwickler vor der Aufgabe die passende Programmstelle selber heraussuchen zu müssen.

 

Wie fange ich an eine Stelle zu suchen?

Als erstes schaue ich mir die Transaktion von der Anwenderseite her an und kläre, was genau gebraucht wird. Hilfreich ist es auch zu ermitteln, welche Alternativen noch möglich wären. Durch die Alternativen bekommt man mehr Handlungspielraum, der später bei der Lösungssuche hilfreich sein kann.

Sobald klar ist, was gebraucht wird, schaue ich als erstes im Customizing (Transaktion SPRO) nach, ob dort mögliche Programmstellen genannt sind. Im Menübaum gibt es an mehreren Stellen Abschnitte zu Systemanpassungen. Hier wird entweder in der Dokumentation zum jeweiligen Customizingpunkt beschrieben welche Stellen es gibt ggf. mit einem direkten Absprung zu einem Badi. Wenn man solche Punkte gefunden hat und dort laut Beschreibung einer davon für die Aufgabenstellung geeignet ist, ist das sehr erfreulich und man spart sich eine durchaus langwierige Suche nach einer Programmstelle. Alternativ kann es ebenfalls hilfreich sein nach einer Programmstelle im Internet oder bei der SAP in den Hinweisen zu suchen.

Wenn dort keine geeignete Programmstelle vorhanden ist, muss man selber eine im Quellcode identifizieren. Am einfachsten ist es, wenn in der Transaktion bereits Felder vorhanden sind, die an einer ähnlichen Stelle eingebaut sind, wo die neuen Sachen ergänzt werden sollen. In Dialogtransaktionen kann man aus der Anwendertransaktion einfach per F1-Hilfe eines Eingabefeldes auf die technischen Informationen zugreifen und von dort aus in den Quellcode des Dynpros springen. Mit etwas Glück sind die Benennungen der Felder und Module ausreichend sprechend, sodass man die Stelle sehr schnell findet. Alternativ lassen sich auch per Verwendungsnachweis auf Datenbanktabellen, Datenelementen usw. Programmstellen finden.

Erst wenn das alles nicht zu dem gewünschten Erfolg führt, fange ich an die Programme zu debuggen, um dabei geeignete Stellen zu finden. Normalerweise überspringe ich dabei viele Routinenaufrufe und steige nur in die Routinen ein, die vom Namen her zu den gewünschten Inhalten passen. Für mein Empfingend geht es schneller, die Transaktion noch einmal von vorne zu debuggen, wenn ich mal eine Stelle übersprungen habe, die ich mir besser genauer angeschaut hätte, als mir jede Routine bis ins Details anzuschauen. Als Hilfsmittel kann man sehr gut Breakpoints im Debugger setzen und speichern, sodass man bei einem Neustart sehr schnell wieder zur letzten Programmstelle gelangt. Auch die Watchpoints sind sehr hilfreich, wenn man eindeutige Einzelfelder kennt, die an den gesuchten Stellen inhaltlich geändert werden müssten.

Wenn man eine Programmstelle gefunden hat, kann man schauen, ob es dort in der Nähe einen geeigneten impliziten oder expliziten Enhancement gibt. Wenn nichts vorhanden ist, kann man auch noch etwas weitersuchen bevor man eine Modifikation anlegt. Häufig lassen sich mehrere ähnliche Stellen für die gleiche Aufgabe verwenden. Erst wenn wirklich nichts zu finden ist, benutze ich eine Modifikation. In Dynpros selber kommt man allerdings nicht um Modifikationen herum, da die Felder im Dynpro und der Ablauflogik ergänzt werden müssen.

Um herauszufinden wo in einem Programm eine bestimmte Funktion ausgeführt wird, die man per Button oder Menüeintrag aufruft, ist es am einfachsten nach dem Funktionscode zu suchen. Der Funktionscode lässt sich herausfinden indem man mit der Maus auf den Button klickt, dabei die Maustaste festhält und die F1-Taste drückt. Dann erscheint ein Popup mit dem Funktionscode. Sollte das mal nicht funktionieren, kann man über die technischen Informationen der F1-Hilfe zu einem Eingabefeld oder über das Menü System –> Status den GUI-Status aufrufen und den Funktionscode auslesen. Danach einfach über den Editor im gesamten Rahmenprogramm nach dem Funktionscode suchen. In manchen Programmen wird allerdings eine Konfigurationstabelle verwendet, um den Funktionscode in Programmroutinen umzuwandeln. Dann hilft es nur nach der Tabelle zu suchen oder zu Debuggen (z.B. den Systembefehl /h für den Debugger im Transaktionsfeld eintippen, die Funktion ausführen und solange debuggen bis man die Tabelle oder den Code gefunden hat).

Sobald man ein oder mehrere Programmstellen hat, kann man per Debugger an genau den Stellen einige Variablen verändern und darüber herausfinden, ob es zu dem gewünschten Ergebnis führt. Das geht allerdings nur, wenn bestehende Felder verändert werden sollen. Ansonsten einen Breakpoint an die Stellen setzen und die Transaktion mit den verschiedenen Anwendungsfällen ausführen. Wenn in einigen Fällen der Breakpoint nicht angesprungen wird, obwohl man die dafür notwendigen Aktionen ausgeführt hat, dann fehlt noch eine Stelle. Gerade bei Änderungsfällen kommt es sehr schnell vor, dass die Verarbeitung leicht unterschiedlich im Standardprogramm verläuft, sodass manchmal mehrere Programmstellen für eigentlich eine Sache in Betrieb genommen werden müssen.

Anschließend lege ich dann für die Programmstellen die Enhancements, Badi’s, Includes usw. an und beginne mit der Implementierung. Je nachdem wie sicher ich mir bin, ob die Stellen tatsächlich geeignet sind, fange ich erst mit einer minimalen Implementierungen an, um die Stellen zu testen oder ich baue es gleich richtig ein.

 

Mehrere Programmstellen für eine Implementierung

Gerade bei größeren Implementierungen reicht es nicht aus, nur eine einzige Programmstelle zu verwenden. Diese Programmteile greifen auf gemeinsame Daten zu. Damit der Zugriff auf die gemeinsamen Daten nicht zu kompliziert wird, nutze ich gerne die Eigenschaft, dass eine Funktionsgruppe oder der statische Teil einer Klasse nur einmal während der Laufzeit geladen wird. Die folgende Abbildung veranschaulicht es. Jede Programmstelle nutzt unterschiedliche Methoden einer Klasse oder Funktionen einer Funktionsgruppe. Die Daten werden als globale Attribute in der Klasse oder Funktionsgruppe gespeichert und können somit von jeder Methode oder Funktion erreicht werden. Sobald der Anwender die Transaktion beendet, werden alle Daten der Programme, Funktionsgruppen oder Klassen gelöscht. Der Ablauf funktioniert ebenfalls, wenn noch mehr Programme, Klassen oder Funktionsgruppen beteiligt sind.

SAP-Programm erweitern

 

Weitere Anmerkungen

Neue Felder in Datenbanktabellen hinzuzufügen und in einer Standardtransaktion einzubauen, geht normalerweise recht einfach. In der Tabellendefinition (Transaktion SE11) kann man Append-Strukturen ergänzen. Für die Darstellung im Dynpro wird zwar eine Modifikation benötigt, aber die Verarbeitungslogik im bestehenden Programm übernimmt häufig schon die Initialisierung, Änderungsüberprüfung und das Speichern des neuen Feldes. Dadurch sind eher wenige und einfache Anpassungen im Programm notwendig, auch wenn man es natürlich durchtesten sollte.

Neue Dynpros, Popups oder ganz neue Datenstrukturen müssen an den verschiedenen Stellen in der Verarbeitungslogik des bestehenden Programms untergebracht werden. Es sind mehrere Programmstellen zu identifizieren, unter anderem für die Initialisierung, Datenselektion, Datenanzeige, Prüfung auf Änderungen und Speicherung.

Ganz neue Elemente in eine Transaktion einzubauen, halte ich eher für unkritisch. Schwieriger wird es, wenn bestehende Verarbeitungslogiken von der SAP übersteuert werden sollen. Wenn es an geplanten Stellen wie User-Exits und Badi’s gemacht wird, ist die Stelle normalerweise schon dafür vorgesehen und es geht recht einfach. Sucht man sich hingegen selber die Stellen heraus, ist zu überprüfen, ob die nicht an anderen Stellen Probleme bereiten, weil die bestehende Transaktion andere Daten erwartet. Außerdem sind immer alle Datenstellen herauszusuchen, da eine Information durchaus temporär in verschiedenen Variablen gespeichert wird. Im Debugger gibt es eine Übersicht mit den globalen Variablen, die es zu einem Rahmenprogramm gibt. Hier lassen sich die schon bestehenden Variablen überprüfen, wenn es denn nicht zu viele sind.

So jetzt hoffe ich, dass Ihnen der Artikel für die Erweiterung eines SAP-Standardprogramms weitergeholfen hat. Bei Fragen und Anregungen schreiben Sie mir einfach.


Beitrag veröffentlicht

in

von

Schlagwörter: