Abgreifen von Daten eines Reports nach SUBMIT
13 Beiträge
•
Seite 1 von 1
13 Beiträge
Seite 1 von 1
Hallo zusammen,
ich hätte da mal ein Problem. :) Gibt es eine Möglichkeit, die Daten eines Reports, der per SUBMIT aufgerufen wurde, abzugreifen? Im konkreten Fall geht es um Report RVSCD100 (Änderungsbelege anzeigen), von dem ich gerne die Daten der Tabelle AUS hätte. Die Daten der allgemeinen Augabe kriege ich problemlos durch Nutzung der Klasse cl_salv_bs_runtime_info, für die Tabellen ohne ALV Bezug nutzt mir das aber nichts. Ich habe schon mit "Dirty Assigns" herumprobiert, bin aber zu keiner Lösung gekommen.
Kann mir hier jemand einen guten Tip geben?
Besten Dank.
ich hätte da mal ein Problem. :) Gibt es eine Möglichkeit, die Daten eines Reports, der per SUBMIT aufgerufen wurde, abzugreifen? Im konkreten Fall geht es um Report RVSCD100 (Änderungsbelege anzeigen), von dem ich gerne die Daten der Tabelle AUS hätte. Die Daten der allgemeinen Augabe kriege ich problemlos durch Nutzung der Klasse cl_salv_bs_runtime_info, für die Tabellen ohne ALV Bezug nutzt mir das aber nichts. Ich habe schon mit "Dirty Assigns" herumprobiert, bin aber zu keiner Lösung gekommen.
Kann mir hier jemand einen guten Tip geben?
Besten Dank.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Für Änderungsbelege gibt es doch Funktionsbausteine. Warum muss man denn da unsauber über ein SUBMIT gehen.
Hab gerade kein SAP zur Hand, aber die FuBa's heißen was mit ...CHANGEDOCUMTENT_READ.
Hab gerade kein SAP zur Hand, aber die FuBa's heißen was mit ...CHANGEDOCUMTENT_READ.
Ja, von der Sache her ist es das, was ich brauche.
Das, was dort beschrieben ist (ALV Ausgabe abgreifen) mache ich schon, das funktioniert auch problemlos. Nur würde ich eben gerne auch an die Daten herankommen, die nicht ALV-relevant sind.
Gegenfrage: Wie hilfreich ist so eine "Belehrung" für mich, bringt sie mich bei meinem Problem in irgendeiner Art weiter? Wie ich Änderungsbelege lese weiß ich, das war hier aber nicht die Frage und hilft mir bei meinem Problem nicht.
Ich brauche genau die Funktionalität, die mir o.g. Report liefert und möchte nach dem SUBMIT auf dessen Daten zugreifen, nicht mehr, nicht weniger.
Ich programmiere jetzt seit über 10 Jahren ABAP, aber ein Submit habe ich noch nicht gebraucht. Es ist nur Bequemlichkeit, wenn man es nutzt. Wenn's sauber werden soll, dann programmiert man eben nach, was dort programmiert wurde.
Das habe ich aktuell mit den BCS-Kennzahlen aus den Tabellen FMBDT und FMIT auch gemacht. Mit die Sachen im SAP-Report angeschaut und geprüft, wie's die SAP macht.
Herzlichen Dank für die weitere Belehrung, die mir ungemein dabei hilft, mein Problem zu lösen. Und damit beende ich diese, für beide Seiten wenig hilfreiche, "Diskussion".
Schönes Restwochenende noch!
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Moin SAP_Coder,SAP_Coder hat geschrieben: ↑01.11.2020 15:21Gegenfrage: Wie hilfreich ist so eine "Belehrung" für mich, bringt sie mich bei meinem Problem in irgendeiner Art weiter? Wie ich Änderungsbelege lese weiß ich, das war hier aber nicht die Frage und hilft mir bei meinem Problem nicht.
Ich brauche genau die Funktionalität, die mir o.g. Report liefert und möchte nach dem SUBMIT auf dessen Daten zugreifen, nicht mehr, nicht weniger.
ich kann dein ursprüngliches Problem gut nachvollziehen - machmal brauche ich auch genau die Daten in dem Format mit genau den speziellen Selektionen und Aufbereitungen wie sie SAP an irgendeiner Stelle zur Verfügung stellt. Ich helfe mir dann meist mit einem impliziten Enhancement an einer Stelle wo ich die Daten sehe und exportiere sie dann wenn das aufrufende Programmsie benötigt ins Memory und greife sie im aufrufenden Programm ab.
Code: Alles auswählen.
IF caller_requests_data.
EXPORT data TO MEMORY id ...
LEAVE PROGRAM.
ENDIFIch programmiere etwas länger als 10 Jahre ABAP und benutze SUBMIT dann wenn es die Situation erfordert. Wenn ein Thema hinreichend komplex ist will man das Rad nicht neu erfinden und alle Fehler die SAP im Laufe der Jahre gemacht hat selber erfahren. Das ist nicht unsauber und hat häufig den Vorteil, dass Neuerungen die SAP ausliefert automatisch mit berücksichtigt werden.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
DeathAndPain • SAP_Coder
Formal ist es unsauber. Die Reihenfolge einer strukturierten Anwendung ist DB-Layer, Application Layer, UI Layer. Die Felder des Reports die hier via SUBMIT bedient werden sollen, gehören zum UI Layer. Nun greift man die Werte dieser Felder ab und verarbeitet diese weiter. Man packt also auf den UI Layer noch einen Application Layer drauf - und das ist unsauber. Zu Testzwecken ja, aber sollte dies die große Aunahme sein.black_adept hat geschrieben: ↑02.11.2020 09:16Das ist nicht unsauber und hat häufig den Vorteil, dass Neuerungen die SAP ausliefert automatisch mit berücksichtigt werden.
Alternativ kann man vielleicht ein Form-Routine aus dem Report aufrufen. Das ist zwar auch nicht schön, aber die Daten müssen nicht erst durch den UI Layer.
Folgende Benutzer bedankten sich beim Autor msfox für den Beitrag:
DeathAndPain
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Würde ich ähnlich sehen, zumal "Neuerungen, die SAP ausliefert" auch zu Inkompatibilitäten zum selbstgebastelten Code führen können, mit der Folge, dass nach einem neuen Support Package auf einmal der Kram nicht mehr funktioniert.
Auf der anderen Seite kann ich die Aussage von msfox, dass man nie SUBMIT brauchen würde, auch nicht unterschreiben. SUBMIT kann man ja nicht nur zu dem hier bislang diskutierten Zweck verwenden. Ich habe schon mehrfach den Fall gehabt, dass ich aus einem Programm (genauer: einem User Exit) heraus ein anderes für Hintergrundverarbeitung einplanen musste, weil die vorzunehmenden Änderungen erst durchgeführt werden konnten, wenn das Hauptprogramm beendet war und seine gesperrten Objekte freigegeben hat. Und da ist SUBMIT auch der Befehl der Wahl für.
Auf der anderen Seite kann ich die Aussage von msfox, dass man nie SUBMIT brauchen würde, auch nicht unterschreiben. SUBMIT kann man ja nicht nur zu dem hier bislang diskutierten Zweck verwenden. Ich habe schon mehrfach den Fall gehabt, dass ich aus einem Programm (genauer: einem User Exit) heraus ein anderes für Hintergrundverarbeitung einplanen musste, weil die vorzunehmenden Änderungen erst durchgeführt werden konnten, wenn das Hauptprogramm beendet war und seine gesperrten Objekte freigegeben hat. Und da ist SUBMIT auch der Befehl der Wahl für.
Hi black_adept,black_adept hat geschrieben:
ich kann dein ursprüngliches Problem gut nachvollziehen - machmal brauche ich auch genau die Daten in dem Format mit genau den speziellen Selektionen und Aufbereitungen wie sie SAP an irgendeiner Stelle zur Verfügung stellt. Ich helfe mir dann meist mit einem impliziten Enhancement an einer Stelle wo ich die Daten sehe und exportiere sie dann wenn das aufrufende Programmsie benötigt ins Memory und greife sie im aufrufenden Programm ab.Code: Alles auswählen.
IF caller_requests_data. EXPORT data TO MEMORY id ... LEAVE PROGRAM. ENDIF
das ist eine gute Lösung, die ich so nutzen kann, vielen Dank dafür.
Deswegen hatte ich "Belehrung" auch in Anführungszeichen geschrieben. Der Hinweis auf die FuBas zum Lesen der Änderungsbelege ist völlig in Ordnung, mir ging es in erster Linie darum, dass sofort wegen des "SUBMIT" geschossen wurde, ohne die Hintergründe zu kennen. Und das ist zumindest wertend und hat meinen entsprechenden Kommentar dazu veranlaßt.black_adept hat geschrieben: Niemand kennt deinen Erfahrungsschatz bzw. was du sonst so probiert hast und der Hinweis auf die FuBa zum Änderungszeigerlesen halte ich für hilfreich und nicht belehrend.
Man kann eine Meinung vertreten, etwas aber sofort als unsauber zu verteufeln, ist für mich nicht zielführend. Und wenn dann, in einem weiteren Beitrag, tatsächlich der Rat gegeben wird, man solle doch einfach den Report der SAP nachprogrammieren, stellen sich mir unweigerlich mehr als nur einige Fragen, speziell dann, wenn ich lesen muss, dass 10 Jahre Erfahrung vorhanden sind... Dass SUBMIT auch in Standardprogrammen der SAP genutzt wird, ist dann nur noch eine kleine Randnotiz wert.
Was meine Erfahrung angeht, wer mit Begriffen wie Z80, 6502/6510 und 68000 Assembler noch etwas anfangen kann, hat ein ungefähres Bild davon, wie lange ich Software entwickle. :)
Ok, dann brauche ich nicht weiter diskutieren. Festgefahren in alten Strukturen.... Beim Studium wurde vermutlich nach nicht das Schichten-Model behandelt.
Vermutlich stehe ich in 10 Jahren an gleicher Stelle, wenn mir einer sagt: "Na in SAP Fiori macht das aber so und so" und ich bin uneinsichtig. Wobei ich an dem Overhead von SAP Fiori jetzt schon zweifle, aber die junge Generation das geil findet...
Trotzdem bleibe ich dabei, dass das SUBMIT und auch CALL TRANSACTION unsauber ist. Es greift Daten von der UI-Schicht ab. Für Testautomatisierung i.O. und im äußersten Notfall, kann man es sich verwenden. Daher gehe ich bei dir mal vom Notfall aus :).
Wenn du in einer Webdynpro Anwendung fertig aufbereitete Daten vorfindest, greifst du diese doch auch nicht mit der Klasse CL_WD_WEB_DYNPRO_TESTER ab und baust daraus deine eigene Anwendung.
Vielleicht geht das:
https://tricktresor.de/blog/exporting-alv-to-memory/
Keine Ahnung, ob das noch bzw. mit dem im Report verwendeten REUSE-Baustein funktioniert.
Aber auch damit kommst du nicht an die programminternen Variablen heran.
Den Einwand von msfox finde ich durchaus berechtigt. Gerade wenn du noch irgendwelche internen Infos benötigst, die der Report nicht ausgibt, ist es zumindest eine Überlegung Wert, sich mal die eigentliche Datenbeschaffung anzusehen.
Aber auch da bin ich bei dir: Wenn es "etwas" gibt, dass mir dir Daten bereits so zusammenstellt, wie ich es benötige, ist es ggfs. einfacher, diese abzugreifen. Auch, wenn man dafür eine nicht optimale Technik nutzen muss.
Meiner Erfahrung nach - und wahrscheinlich hat msfox ähnliche Erfahrungen gemacht - entstehen so die "fiesesten" Programme: Man nimmt was vermeintlich Einfaches und programmiert hinterher trotzdem soviel drumherum und nimmt merkwürdige Datenkonstellationen in Kauf, die das Programm am Ende unwartbar machen.
https://tricktresor.de/blog/exporting-alv-to-memory/
Keine Ahnung, ob das noch bzw. mit dem im Report verwendeten REUSE-Baustein funktioniert.
Aber auch damit kommst du nicht an die programminternen Variablen heran.
Den Einwand von msfox finde ich durchaus berechtigt. Gerade wenn du noch irgendwelche internen Infos benötigst, die der Report nicht ausgibt, ist es zumindest eine Überlegung Wert, sich mal die eigentliche Datenbeschaffung anzusehen.
Aber auch da bin ich bei dir: Wenn es "etwas" gibt, dass mir dir Daten bereits so zusammenstellt, wie ich es benötige, ist es ggfs. einfacher, diese abzugreifen. Auch, wenn man dafür eine nicht optimale Technik nutzen muss.
Meiner Erfahrung nach - und wahrscheinlich hat msfox ähnliche Erfahrungen gemacht - entstehen so die "fiesesten" Programme: Man nimmt was vermeintlich Einfaches und programmiert hinterher trotzdem soviel drumherum und nimmt merkwürdige Datenkonstellationen in Kauf, die das Programm am Ende unwartbar machen.
So, nun ist das Eis gebrochen :). Ich habe ein Anforderung auf dem Tisch, wo über die Webdynpros verschiedenen Transaktion/Reports ausgeführt werden sollen. Hierzu ist natürlich überhaupt nicht angedacht, dass man dafür erst jeden Report noch einmal webfähig nachprogrammiert.
Hat es mich also doch noch getroffen...
Seite 1 von 1
Vergleichbare Themen
8
Antw.
Antw.
1283
Views
Views
7
Antw.
Antw.
4487
Views
Views
Reports zum Löschen unbenötigter Reports
von Tunoto » 28.02.2006 16:45 • Verfasst in ABAP® für Anfänger
von Tunoto » 28.02.2006 16:45 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
2271
Views
Views
0
Antw.
Antw.
1263
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 2 Tagen von DeathAndPain 4 / 1045
vor 2 Tagen von DeathAndPain 4 / 1045
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 2 Tagen von DeathAndPain 4 / 1045
vor 2 Tagen von DeathAndPain 4 / 1045