Frage zu ABAP Object und Funktionsbausteine
Hallo zusammen!
Ich hab mal eine Frage zu ABAP Objects in Kombination mit Funktionsbausteinen.
Angenommen es existiert ein Funktionsbaustein Z_ADDIERE_ZAHLEN (Import: 2 Zahlen Export: 1 Zahl)
Ich möchte diesen Funktionsbaustein aus einer Objekt Methode aufrufen die zur Klasse TASCHENRECHNER gehört.
Ich hab allerdings im Internet gelesen, dass so etwas nur engeschränkt möglich ist?
Ich könnte doch eine Methode ADDIERE der Klasse TASCHENRECHNER erstellen und dort den Funktionsbaustein aufrufen?
Wie ist es denn dann mit den bereits vorhandenen SAP Funktionsbausteinen? Z.B. wen ich Daten einer Excel Liste in eine interne Tabelle laden möchte?
Dann könnte ich doch eine Klasse "DATEI" erstellen und in dieser Klasse kann ich eine Methode erstellen, die den Funktionsbaustein aufruft?
Würdet Ihr mir hier bitte helfen?
Danke!
Viele Grüße!!
Ich hab mal eine Frage zu ABAP Objects in Kombination mit Funktionsbausteinen.
Angenommen es existiert ein Funktionsbaustein Z_ADDIERE_ZAHLEN (Import: 2 Zahlen Export: 1 Zahl)
Ich möchte diesen Funktionsbaustein aus einer Objekt Methode aufrufen die zur Klasse TASCHENRECHNER gehört.
Ich hab allerdings im Internet gelesen, dass so etwas nur engeschränkt möglich ist?
Ich könnte doch eine Methode ADDIERE der Klasse TASCHENRECHNER erstellen und dort den Funktionsbaustein aufrufen?
Wie ist es denn dann mit den bereits vorhandenen SAP Funktionsbausteinen? Z.B. wen ich Daten einer Excel Liste in eine interne Tabelle laden möchte?
Dann könnte ich doch eine Klasse "DATEI" erstellen und in dieser Klasse kann ich eine Methode erstellen, die den Funktionsbaustein aufruft?
Würdet Ihr mir hier bitte helfen?
Danke!
Viele Grüße!!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Hi!
Als Beispiel schau dir mal die Methode CL_GUI_FRONTEND_SERVICES=>GUI_UPLOAD an. Das ist SAP Standard und intern wird der FuBa GUI_UPLOAD aufgerufen.
lg ADT
Aber sicher!Mark33 hat geschrieben:Würdet Ihr mir hier bitte helfen?
Meine Spezialität.Mark33 hat geschrieben:Ich hab mal eine Frage zu ABAP Objects in Kombination mit Funktionsbausteinen.
Mich würde interessieren wo du das gelesen hast, ist mir nämlich nicht bekannt, dass es da eine Einschränkung gäbe.Mark33 hat geschrieben:Ich hab allerdings im Internet gelesen, dass so etwas nur engeschränkt möglich ist?
Als Beispiel schau dir mal die Methode CL_GUI_FRONTEND_SERVICES=>GUI_UPLOAD an. Das ist SAP Standard und intern wird der FuBa GUI_UPLOAD aufgerufen.
Jepp, würde ich auch so machen. Und wenn du irgendwann merkst, dass der FuBa irgendwas nicht kann was du eigentlich brauchen würdest, kannst du dann selbst die Methode ADDIERE programmieren, ohne die Aufrufstellen ändern zu müssen.Mark33 hat geschrieben:Ich könnte doch eine Methode ADDIERE der Klasse TASCHENRECHNER erstellen und dort den Funktionsbaustein aufrufen?
Siehe meine dritte Antwort.Mark33 hat geschrieben:Wie ist es denn dann mit den bereits vorhandenen SAP Funktionsbausteinen?
Die Excel-Bausteine kenn ich jetzt zwar nicht so gut, aber ich sag mal: JaMark33 hat geschrieben:Z.B. wen ich Daten einer Excel Liste in eine interne Tabelle laden möchte?
Ja. Ich würde die Klasse nur nicht gerade DATEI nennen, sondern eher eine Hauptklasse die DATEI heißt und nur einfache Methoden zum Laden und Speichern bietet. Die Excel-spezifischen Sache würde ich dann in der Klasse EXCEL_DATEI implementieren die von DATEI abgeleitet ist... Aber jetzt die Vorteile von Vererbung aufzuzählen würde den Rahmen sprengenMark33 hat geschrieben:Dann könnte ich doch eine Klasse "DATEI" erstellen und in dieser Klasse kann ich eine Methode erstellen, die den Funktionsbaustein aufruft?
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
HI!
Danke danke danke für die Tipps die du mir gegeben hast!!!!!
Objektorientierte Programmierung kenn ich von JAVA und C++. Aber bei ABAP lerne ich das gerade.
Hier mal die Textpassage zu Objects und Funktionsbausteine:
http://blog.boxedpages.net/2012/04/26/a ... austeinen/
Da Funktionsbausteine oder Function Modules jedoch keineswegs mit ABAP Objects interagieren können (und wenn dann nur eingeschränkt) ist es wichtig zu wissen, dass Funktionsbausteine mit bspw. WebDynpro for ABAP nicht laufen werden und auch nicht laufen können, zumindest nicht direkt.
Ist das dann hier einfach falsch angegeben, oder ist bei WebDynpros wieder was anderes zu beachten?
Danke!
Viele Grüße
Danke danke danke für die Tipps die du mir gegeben hast!!!!!
Objektorientierte Programmierung kenn ich von JAVA und C++. Aber bei ABAP lerne ich das gerade.
Hier mal die Textpassage zu Objects und Funktionsbausteine:
http://blog.boxedpages.net/2012/04/26/a ... austeinen/
Da Funktionsbausteine oder Function Modules jedoch keineswegs mit ABAP Objects interagieren können (und wenn dann nur eingeschränkt) ist es wichtig zu wissen, dass Funktionsbausteine mit bspw. WebDynpro for ABAP nicht laufen werden und auch nicht laufen können, zumindest nicht direkt.
Ist das dann hier einfach falsch angegeben, oder ist bei WebDynpros wieder was anderes zu beachten?
Danke!
Viele Grüße
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
naja, der Autor geht nicht wirklich auf die "Einschränkungen" ein.
Die einzige wirkliche Einschränkung die ich kenne ist genau umgekehrt, dass Objekte/Klassen keine Dynpros beinhalten dürfen.
Außerdem ist die OO-Syntax in vielen Bereichen strikter und man darf gewisse Befehle und Befehlskombinationen nicht mehr verwenden.
z.B. Tabellen mit Kopfzeile
Was mir in Bezug auf WebDynpros und FuBa noch einfällt ist, dass WebDynpros keine impliziten Commits beinhalten (dürfen).
Dadurch wurde im "alten" ABAP bei jedem Dynprowechsel, Funktionsbausteinaufruf usw. ein Datenbank-Commit ausgelöst.
Daher muss man oft mit den sog. Verbucherbausteinen arbeiten, die eine Art DB-Transaktions-Kapsel anbieten und erst wenn wirklich alle Schritte/Daten vorhanden sind, kann man diese mit COMMIT WORK in die DB übernehmen.
Die WebDynpros hingegen stetzen meines Wissen auf die sog. persistenten Objekte. Dabei werden pro DB-Tabelle eigene Klassen angelegt, die Methoden zum Hinzufügen/Ändern/Entfernen bieten und DB-Transaktionen mit mehreren Leveln (START TRANSAKTION/ROLLBACK) unterstützen.
Jedoch kann man bei jedem Webdynpro Events (oder waren es Badis?) definieren, die dann im ABAP-Code ausgeführt werden. Da kann man meines Wissen dann aber trotzdem wieder FuBas verwenden.
lg
Matthias
Die einzige wirkliche Einschränkung die ich kenne ist genau umgekehrt, dass Objekte/Klassen keine Dynpros beinhalten dürfen.
Außerdem ist die OO-Syntax in vielen Bereichen strikter und man darf gewisse Befehle und Befehlskombinationen nicht mehr verwenden.
z.B. Tabellen mit Kopfzeile
Was mir in Bezug auf WebDynpros und FuBa noch einfällt ist, dass WebDynpros keine impliziten Commits beinhalten (dürfen).
Dadurch wurde im "alten" ABAP bei jedem Dynprowechsel, Funktionsbausteinaufruf usw. ein Datenbank-Commit ausgelöst.
Daher muss man oft mit den sog. Verbucherbausteinen arbeiten, die eine Art DB-Transaktions-Kapsel anbieten und erst wenn wirklich alle Schritte/Daten vorhanden sind, kann man diese mit COMMIT WORK in die DB übernehmen.
Die WebDynpros hingegen stetzen meines Wissen auf die sog. persistenten Objekte. Dabei werden pro DB-Tabelle eigene Klassen angelegt, die Methoden zum Hinzufügen/Ändern/Entfernen bieten und DB-Transaktionen mit mehreren Leveln (START TRANSAKTION/ROLLBACK) unterstützen.
Jedoch kann man bei jedem Webdynpro Events (oder waren es Badis?) definieren, die dann im ABAP-Code ausgeführt werden. Da kann man meines Wissen dann aber trotzdem wieder FuBas verwenden.
lg
Matthias
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo,
ich bin hier zufällig auf den Thread mit meinem Link darin gestoßen.
Das ABAP-Tutorial ist wirklich nur für Einsteiger gedacht, und um für den Anfang nicht unnötig mit teils zu detaillierten Aussagen zu verwirren, habe ich mich dazu entschieden einige Dinge im Tutorial explizit nicht anzugeben.Zu ABAP Objects komme ich auch irgendwann einmal (wenn mir eines Tages genügend Ideen kommen). In erster Linie geht es darum schnell erste Erfolge mit ABAP zu erzielen wenn man eben erst einsteigt oder komplett umsteigt von Java oder ähnlichem.
Viele Grüße
Christian
ich bin hier zufällig auf den Thread mit meinem Link darin gestoßen.
Das ABAP-Tutorial ist wirklich nur für Einsteiger gedacht, und um für den Anfang nicht unnötig mit teils zu detaillierten Aussagen zu verwirren, habe ich mich dazu entschieden einige Dinge im Tutorial explizit nicht anzugeben.Zu ABAP Objects komme ich auch irgendwann einmal (wenn mir eines Tages genügend Ideen kommen). In erster Linie geht es darum schnell erste Erfolge mit ABAP zu erzielen wenn man eben erst einsteigt oder komplett umsteigt von Java oder ähnlichem.
Viele Grüße
Christian
Beitrag
von ralf.wenzel (Top Expert / 3922 / 200 /
280
)
»
Ich frag einfach mal doof: Was bringt das? Da kann ich doch gleich den Funktionsbaustein direkt aufrufen....a-dead-trousers hat geschrieben:Methode CL_GUI_FRONTEND_SERVICES=>GUI_UPLOAD (...) Das ist SAP Standard und intern wird der FuBa GUI_UPLOAD aufgerufen.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4086 / 126 /
940
)
»
Aber wenn du das direkt aufrufst bist du halt kein supercooler OO-Experte sondern ein ABAP-Dino.
Beitrag
von ralf.wenzel (Top Expert / 3922 / 200 /
280
)
»
Ahhhhhja - weiß jemand vielleicht noch einen wirklich GUTEN Grund? 
Die SAP wird sich doch was dabei überlegt haben. Oder etwa nicht?
Die SAP wird sich doch was dabei überlegt haben. Oder etwa nicht?
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
ralf.wenzel hat geschrieben:Ahhhhhja - weiß jemand vielleicht noch einen wirklich GUTEN Grund?
Die SAP wird sich doch was dabei überlegt haben. Oder etwa nicht?
Ist doch eine Scherzfrage um Anfaenger zu verunsichern, oder?!?!?
Du kannst den Upload auch "zu Fuss" programmieren und brauchst weder die Methode noch den Fuba aufrufen.
Beitrag
von ralf.wenzel (Top Expert / 3922 / 200 /
280
)
»
Nein, das ist keine Scherzfrage - ich möchte wissen, warum die SAP den Funktionsbaustein als obsolet bezeichnet und stattdessen den Aufruf einer Methode propagiert, die nichts anderes macht als den FB zu kapseln.
Das ist eine ganz ernst gemeinte Frage.
Das ist eine ganz ernst gemeinte Frage.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Vielleicht um den "alten" FuBa später mal entfernen zu können und durch eine neue API zu ersetzen.
Aber dann ist ihnen scheinbar die "Inspiration" ausgegangen.
Mir persönlich sind Methoden schon von daher sympatischer, weil die Syntax-Prüfung sofort greift.
Im Gegensatz zu einem Funktionsbaustein, bei dem man das aufrufende Programm auch aktivieren kann, wenn man die Schnittstelle geändert hat.
lg ADT
Aber dann ist ihnen scheinbar die "Inspiration" ausgegangen.
Mir persönlich sind Methoden schon von daher sympatischer, weil die Syntax-Prüfung sofort greift.
Im Gegensatz zu einem Funktionsbaustein, bei dem man das aufrufende Programm auch aktivieren kann, wenn man die Schnittstelle geändert hat.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von ralf.wenzel (Top Expert / 3922 / 200 /
280
)
»
Also, ich würde ja verstehen, wenn man eine instanziierbare Klasse baut, die z. B. die Funktionsbausteine für das Application Log oder Batch Input in einer Klasse kapselt, das hätte einen Mehrwert. Aber so verstehe ich es halt nicht.....
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Also ADT hat meiner Meinung nach die beiden wichtigsten Gründe genannt. Das finde ich ziemlich nachvollziehbar.ralf.wenzel hat geschrieben:Also, ich würde ja verstehen, wenn man eine instanziierbare Klasse baut, die z. B. die Funktionsbausteine für das Application Log oder Batch Input in einer Klasse kapselt, das hätte einen Mehrwert. Aber so verstehe ich es halt nicht.....
Zudem hat die SAP mit den CL_GUI_FRONTEND_SERVICES eine Gruppe von Tools zusammen gestellt, zu dem eben auch der bereits vorhandene Upload und Download von Dateien dazu gehört. Warum das Rad zweimal erfinden? Wenn SAP die Klasse ohne die gekapselten Up- und Downloadmethoden ausgeliefert hätte, hättest du mit Sicherheit auch angemeckert, dass man die doch auch damit hätte zu packen können, oder?
Zudem vermischst du zwei Dinge: Du verstehst nicht, warum der upload-Baustein in einer statischen Methode verwendet wird und nennst als Grund, dass man das Application Log in einer instanziierbaren Klasse kapseln könnte...
Das wiederum ist übrigens nicht ganz ohne. Ich habe es mehrmals gemacht und bin mehrmals über fiese Fallen bei der Vererbung gestolpert. Angefangen damit, dass zu einem ordentlichen Application Log auch eine eigene Struktur gehört. Die kann aber nicht so einfach vererbt um dann in der Unterklasse redefiniert zu werden...
Beitrag
von ralf.wenzel (Top Expert / 3922 / 200 /
280
)
»
Nur, wenn durch den objektorientierten Ansatz Vorteile bei rauskommen (eiweh, Grammattttttttik LOL). Ich denke schon, dass man da etwas hätte basteln können, das den ganzen Weg schön zusammenfasst, der z. B. die Werthilfe mit berücksichtigt und Ähnliches. Normalerweise verwendet man ja nicht nur den Up-/Download. Vielleicht ist das jetzt VON MIR zu kurz gedacht, aber wenn man auf diesem Wege dahin kommen würde, dass man go_datei->delete, go_datei->upload, go_datei->list_dir verwenden kann (und zwar für unterschiedliche Dateien in demselben Programm), hätte man wirklich etwas gewonnen im Sinne von technischem Fortschritt, der weit über das hinausgeht, was man mit einer statischen Methode erreichen kann, die einfach nur den Funktionsbaustein kapselt.ewx hat geschrieben:Also ADT hat meiner Meinung nach die beiden wichtigsten Gründe genannt. Das finde ich ziemlich nachvollziehbar.
Zudem hat die SAP mit den CL_GUI_FRONTEND_SERVICES eine Gruppe von Tools zusammen gestellt, zu dem eben auch der bereits vorhandene Upload und Download von Dateien dazu gehört. Warum das Rad zweimal erfinden?
Genau DIE Beispiele sind es nämlich, die ein Java-Entwickler (als Ausdruck) lachend in die Luft hält und sagt "hey, guckt mal, die SAP wird jetzt mega objektorientiert"....
Also, das mit dem Application-Log ist jetzt ein doofes Beispiel, weil man davon selten mehr als eines in einem Programm brauchtewx hat geschrieben:Zudem vermischst du zwei Dinge: Du verstehst nicht, warum der upload-Baustein in einer statischen Methode verwendet wird und nennst als Grund, dass man das Application Log in einer instanziierbaren Klasse kapseln könnte...
Das wiederum ist übrigens nicht ganz ohne. Ich habe es mehrmals gemacht und bin mehrmals über fiese Fallen bei der Vererbung gestolpert. Angefangen damit, dass zu einem ordentlichen Application Log auch eine eigene Struktur gehört. Die kann aber nicht so einfach vererbt um dann in der Unterklasse redefiniert zu werden...
Aber gerade das wollte ich mal umsetzen - interessanterweise scheint das nicht so trivial zu sein, wie ich mir das vorstelle. Umso mehr reizt es mich, das mal zu versuchen.Und hey, ich will nicht stänkern - ich will diskutieren
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Dass SAP da einfach die Upload- und Download-FBs gekapselt hat, ist an sich nicht schlimm.ewx hat geschrieben:Zudem hat die SAP mit den CL_GUI_FRONTEND_SERVICES eine Gruppe von Tools zusammen gestellt, zu dem eben auch der bereits vorhandene Upload und Download von Dateien dazu gehört.
Eher schon, dass da offenbar nicht einmal minimal darüber nachgedacht wurde, wie die Schnittstelle idealerweise aussehen sollte.
Denn der FB GUI_DOWNLOAD hat mit Sicherheit keinen vernünftigen Grund, die übergebenen Daten, die dann in eine lokale Datei heruntergeladen werden sollen, zu verändern.
Das heißt, auch wenn der FB hier einen TABLES-Parameter verwendet, hätte die ABAP-OO-Methode hier gefälligst einen IMPORTING-Parameter anzubieten und nicht einen CHANGING-Parameter.
Um die (erweiterte) Syntaxprüfung und/oder Code Inspector ruhig zu stellen, hätte es verschiedene mögliche Lösungen gegeben.
a)
FB-Schnittstelle um einen optionalen IMPORTING-Parameter erweitern, der statt des TABLES-Parameters für den Download benutzt wird, sofern dieser Parameter übergeben wird
b)
In der ABAP-OO-Methode mit CREATE DATA ... eine Kopie erzeugen, die statt des IMPORTING-Parameters an den FB übergeben wird (in allen halbwegs aktuellen SAP-Kerneln ist wg. Copy-on-Write hier nicht zu befürchten, dass vorübergehend doppelt so viel Hauptspeicher benötigt wird)
So muss sich jetzt jeder Entwickler in seinen eigenen Programmen damit herumärgern, dass er mit CHANGING-Parametetn hantieren muss, auch wenn klar ist, dass an bestimmten Stellen keine Daten-Änderungen vorkommen können/sollten, oder man kapselt die ABAP-OO-Methode oder den FB noch mal in einer eigenen Klasse.
Beides nicht wirklich zufriedenstellend.
Frank
Vergleichbare Themen
4
Antw.
Antw.
735
Views
Views
Abap Object Method für interne Tabelle
von msentaburlar » 06.01.2020 16:34 • Verfasst in ABAP® für Anfänger
von msentaburlar » 06.01.2020 16:34 • Verfasst in ABAP® für Anfänger
9
Antw.
Antw.
3794
Views
Views
2
Antw.
Antw.
1658
Views
Views
1
Antw.
Antw.
2514
Views
Views
2
Antw.
Antw.
1292
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 19 Stunden von DeathAndPain 4 / 837
vor 19 Stunden von DeathAndPain 4 / 837
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 19 Stunden von DeathAndPain 4 / 837
vor 19 Stunden von DeathAndPain 4 / 837