Ermitteln der Inhalte eines Selektionsschirms
8 Beiträge
•
Seite 1 von 1
8 Beiträge
Seite 1 von 1
Beitrag
von a-dead-trousers (Top Expert / 4485 / 231 /
1205
)
»
hi!
Ich bin gerade auf der Suche nach einer Möglichkeit den aktuellen Inhalt eines Selektionsbildschirms AUßERHALB des zugehörigen Programms zu ermitteln.
Hintergrund ist, dass ich eine Funktion erstellen möchten um Reports die mandantenabhängig sind auf mehreren Mandanten ausführen zu können.
Meine Firma hat sich vor Jahren (leider) dazu entschlossen für jeden Standort einen eigenen Mandanten anzulegen. Dementsprechend aufwändig sind dann gewisse Auswertungen zu gestalten.
Teilweise haben wir uns dadurch beholfen, Standardreports zu kopieren und unter Verwendung von CLIENT SPECIFIED mehrmandantenfähig zu machen.
Natürlich auch mit Nachteil, dass dadurch Neuerungen durch Hinweise im Standrad oft übersehen werden.
Ich suche nun nach einer Lösung, die es uns erlaubt die Standard Reports per RFC auf den jeweiligen Mandanten auszuführen. Hat natürlich en Nachteil, dass man dann die Selektion für jeden einzelnen Mandanten auswählen muss und auch die Ergebnisliste für jeden Mandanten extra angezeigt wird.
Mir schwebt nun eine Lösung vor die per SUBMIT ... EXPORTING LIST TO MEMORY die Ergebnisse sammelt.
Ich weiß, dass es dann trotzdem bei Reports die explizit ALV Grid in einem Custom-Container verwenden oder zusätzlich Funktionen in der Liste anbieten möglicherweise nicht funktionieren werden. Das ist jetzt aber nicht mein Hauptproblem.
Ich möchte, dass die User wenn möglich nur eine einzige Selektion ausfüllen müssen und dann alle weiteren Aufrufe von SUBMIT mit WITH SELECTION-TABLE ablaufen können.
Dazu muss ich entweder einen Weg finden die AKTUELLEN Daten aus dem Selektionsschirm auszulesen, oder den Selektionsschirm UNABHÄNGIG vom eigentlichen Report aufzurufen.
Für Varaiante eins habe ich Versuche mit den RS_VARIANT* Bausteinen nach der Ausführung des Reports angestellt. Nur scheinen hier die Daten für die Bausteine nicht mehr zur Verfügung zu stehen. Gibt es vielleicht einen User-Exit oder ein Badi mit denen ich in die Reportverarbeitung direkt eingreifen kann? Gibt es vielleicht noch andere Bausteine die die Daten vielleicht aus anderen Quellen (RSDBRUNT, RSDBSPVA, RSSYSTDB, usw.) herauskitzeln können?
Bei Variante zwei bin ich leider überhaupt nicht fündig geworden. Man kann zwar die Struktur/Felder eines Selektionsschirms z.B. mit RS_REPORTSELECTSCREEN_INFO auslesen. Nur wie man dann einen Selektionsschirm "emulieren" könnte hab ich keinen Ahnung. Gibt es vielleicht einen Möglichkeit den Selektionsschirm in eine FREE SELECTION umzuwandeln?
Bitte um Anregungen und weitere Denkanstöße.
lg ADT
Ich bin gerade auf der Suche nach einer Möglichkeit den aktuellen Inhalt eines Selektionsbildschirms AUßERHALB des zugehörigen Programms zu ermitteln.
Hintergrund ist, dass ich eine Funktion erstellen möchten um Reports die mandantenabhängig sind auf mehreren Mandanten ausführen zu können.
Meine Firma hat sich vor Jahren (leider) dazu entschlossen für jeden Standort einen eigenen Mandanten anzulegen. Dementsprechend aufwändig sind dann gewisse Auswertungen zu gestalten.
Teilweise haben wir uns dadurch beholfen, Standardreports zu kopieren und unter Verwendung von CLIENT SPECIFIED mehrmandantenfähig zu machen.
Natürlich auch mit Nachteil, dass dadurch Neuerungen durch Hinweise im Standrad oft übersehen werden.
Ich suche nun nach einer Lösung, die es uns erlaubt die Standard Reports per RFC auf den jeweiligen Mandanten auszuführen. Hat natürlich en Nachteil, dass man dann die Selektion für jeden einzelnen Mandanten auswählen muss und auch die Ergebnisliste für jeden Mandanten extra angezeigt wird.
Mir schwebt nun eine Lösung vor die per SUBMIT ... EXPORTING LIST TO MEMORY die Ergebnisse sammelt.
Ich weiß, dass es dann trotzdem bei Reports die explizit ALV Grid in einem Custom-Container verwenden oder zusätzlich Funktionen in der Liste anbieten möglicherweise nicht funktionieren werden. Das ist jetzt aber nicht mein Hauptproblem.
Ich möchte, dass die User wenn möglich nur eine einzige Selektion ausfüllen müssen und dann alle weiteren Aufrufe von SUBMIT mit WITH SELECTION-TABLE ablaufen können.
Dazu muss ich entweder einen Weg finden die AKTUELLEN Daten aus dem Selektionsschirm auszulesen, oder den Selektionsschirm UNABHÄNGIG vom eigentlichen Report aufzurufen.
Für Varaiante eins habe ich Versuche mit den RS_VARIANT* Bausteinen nach der Ausführung des Reports angestellt. Nur scheinen hier die Daten für die Bausteine nicht mehr zur Verfügung zu stehen. Gibt es vielleicht einen User-Exit oder ein Badi mit denen ich in die Reportverarbeitung direkt eingreifen kann? Gibt es vielleicht noch andere Bausteine die die Daten vielleicht aus anderen Quellen (RSDBRUNT, RSDBSPVA, RSSYSTDB, usw.) herauskitzeln können?
Bei Variante zwei bin ich leider überhaupt nicht fündig geworden. Man kann zwar die Struktur/Felder eines Selektionsschirms z.B. mit RS_REPORTSELECTSCREEN_INFO auslesen. Nur wie man dann einen Selektionsschirm "emulieren" könnte hab ich keinen Ahnung. Gibt es vielleicht einen Möglichkeit den Selektionsschirm in eine FREE SELECTION umzuwandeln?
Bitte um Anregungen und weitere Denkanstöße.
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
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4159 / 136 /
960
)
»
Hallo adt,
so ganz verstanden habe ich leider nicht, was dir zu welchem Zeitpunkt zur Verfügung steht und was nicht.
Aber ich probiere mal folgenden Hinweis.
Auslesen des aktuellen Selektionsbildschirms: FuBa RS_REFRESH_FROM_SELECTOPTIONS liefert dir eine Tabelle zurück vom Typ RSPARAMS ( welche bei SUBMIT ... WITH SELECTION-TABLE benötigt wird )
so ganz verstanden habe ich leider nicht, was dir zu welchem Zeitpunkt zur Verfügung steht und was nicht.
Aber ich probiere mal folgenden Hinweis.
Auslesen des aktuellen Selektionsbildschirms: FuBa RS_REFRESH_FROM_SELECTOPTIONS liefert dir eine Tabelle zurück vom Typ RSPARAMS ( welche bei SUBMIT ... WITH SELECTION-TABLE benötigt wird )
Beitrag
von a-dead-trousers (Top Expert / 4485 / 231 /
1205
)
»
hi!
Danke, Hab ich schon ausprobiert, funktioniert nicht.
Grob möchte ich entweder:
Mein Programm -> SUBMIT REPORT UND RETURN -> Dananch RSPARAMS aus dem Report -> SUBMIT REPORT WITH SELECTION-TABLE AND RETURN.
Oder:
Mein Programm -> Aufruf Selektionsdynpro des fremden Reports -> RSPARAMS ermitteln -> SUBMIT REPORT WITH SELECTION-TABLE AND RETURN.
Dazwischen sollen noch an verschiedenen Stellen RFC Aufrufe kommen, die ich jetzt der Einfachheit halber weggelassen habe. Aufgrund dessen ich aber auch irgendwie auf diesen Ablauf angeweisen bin.
Da die gerufenen Reports auch Standardreports sein sollen, möchte ich diese für mein Vorhaben nicht verändern müssen.
Ich hoffe damit hab ich mein Unterfangen etwas klarer dargestellt.
lg ADT
Danke, Hab ich schon ausprobiert, funktioniert nicht.
Grob möchte ich entweder:
Mein Programm -> SUBMIT REPORT UND RETURN -> Dananch RSPARAMS aus dem Report -> SUBMIT REPORT WITH SELECTION-TABLE AND RETURN.
Oder:
Mein Programm -> Aufruf Selektionsdynpro des fremden Reports -> RSPARAMS ermitteln -> SUBMIT REPORT WITH SELECTION-TABLE AND RETURN.
Dazwischen sollen noch an verschiedenen Stellen RFC Aufrufe kommen, die ich jetzt der Einfachheit halber weggelassen habe. Aufgrund dessen ich aber auch irgendwie auf diesen Ablauf angeweisen bin.
Da die gerufenen Reports auch Standardreports sein sollen, möchte ich diese für mein Vorhaben nicht verändern müssen.
Ich hoffe damit hab ich mein Unterfangen etwas klarer dargestellt.
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 black_adept (Top Expert / 4159 / 136 /
960
)
»
Guten Morgen adt,
ich hätte da evtl. eine Methode. Ich skizziere die mal ganz grob - vielleicht ist die für dich gangbar . Hängt auch ein wenig davon ab, ob die Reports die du aufrufst das zulassen aber ich bin da recht zuversichtlich, da ich diese Technik auch schon in anderem Zusammenhang ähnlich verwendet habe.
Die Idee ist dir eine Kopie des Programms anzulegen, welche aber bei Änderungen am Original automatisch mit geändert wird, welches eigentlich nichts anderes macht als die Selektionsparameter auszulesen und im Memory abzulegen. Die gleich beschriebene Vorgehensweise ist so einfach gestrickt, dass dies entweder dynamisch geschehen kann ( INSERT REPORT, GENERATE REPORT !!!!!!DANGER!!!!!!! ) oder aber dass du das Verfahren auf jedes fragliche Programm 1x anwendest und dir eine "Selektionsbild"-Kopie des Programms anlegst.
Zum Verfahren: Wenn du eine Spezialkopie des Programms hast solltest mit einem Aufruf wie dem folgenden das Selektionsbild abgegriffen werden können. Im folgenden Beispielcoding habe ich die Spezialkopie des Programms BALVST01 unter dem Namen "ZSS_TEST1B" gespeichert.
Und nun zum spannenden Teil, der die Spezialkopie des aufzurufenden Originalprogramms darstellt.
Die Idee hier ist folgende:
Da der Zeitpunkt "AT SELECTION-SREEN" leider nur einfach im Programm definiert werden kann muss ein anderer Zeitpunkt gewählt werden, an dem wir die Daten abgreifen können. Dazu legen wir einen im Originalprogramm nicht vorkommenden Parameter an für den wir einen Zeitpunkt "AT SELECTION-SCREEN on neuer_parameter" definieren.
Zu diesem neuen Zeitpunkt wird das Selektionsbild ausgelesen, ins Memory exportiert und dann via "LEAVE PROGRAM" zurück ins rufende Programm gesprungen wo dann die Daten des Selektionsbilds vorhanden sind.
Der neue Parameter wird ganz am Ende des Originalselektionsbildes eingeschleust ( no-display damit der User nicht verwirrt wird ), so dass alle SelScreenprozesse vor AT SELECTION-SCREEN durchlaufen worden sind.
Nachteil. Der Zeitpunkt "AT SELECTION-SCREEN" des Originalprogramms wird leider nicht mehr durchlaufen, so dass dort eingebaute Prüfungen nicht mehr ziehen. Aber evtl. ist das ja zu verschmerzen.
Hier nun der Aufbau des Programms. Nur die 1. Zeile ist dynamisch - dort bitte den Namen des Originalprogramms einsetzen - der Rest ist konstant und könnte auch via Include eingebaut werden, so dass deine Spezialkopie letztlich nur aus 2 Includeanweisungen bestehen müsste.
ich hätte da evtl. eine Methode. Ich skizziere die mal ganz grob - vielleicht ist die für dich gangbar . Hängt auch ein wenig davon ab, ob die Reports die du aufrufst das zulassen aber ich bin da recht zuversichtlich, da ich diese Technik auch schon in anderem Zusammenhang ähnlich verwendet habe.
Die Idee ist dir eine Kopie des Programms anzulegen, welche aber bei Änderungen am Original automatisch mit geändert wird, welches eigentlich nichts anderes macht als die Selektionsparameter auszulesen und im Memory abzulegen. Die gleich beschriebene Vorgehensweise ist so einfach gestrickt, dass dies entweder dynamisch geschehen kann ( INSERT REPORT, GENERATE REPORT !!!!!!DANGER!!!!!!! ) oder aber dass du das Verfahren auf jedes fragliche Programm 1x anwendest und dir eine "Selektionsbild"-Kopie des Programms anlegst.
Zum Verfahren: Wenn du eine Spezialkopie des Programms hast solltest mit einem Aufruf wie dem folgenden das Selektionsbild abgegriffen werden können. Im folgenden Beispielcoding habe ich die Spezialkopie des Programms BALVST01 unter dem Namen "ZSS_TEST1B" gespeichert.
Code: Alles auswählen.
REPORT.
DATA: %%gt_rsparams TYPE rsparams_tt.
FREE MEMORY ID '%%GT_RSPARAMS'.
* Das hier muss vor dem Aufruf angelegt worde sein oder dynamisch generiert werden.
SUBMIT zss_test1b VIA SELECTION-SCREEN AND RETURN.
IMPORT %%gt_rsparams FROM MEMORY ID '%%GT_RSPARAMS'.
BREAK-POINT.Die Idee hier ist folgende:
Da der Zeitpunkt "AT SELECTION-SREEN" leider nur einfach im Programm definiert werden kann muss ein anderer Zeitpunkt gewählt werden, an dem wir die Daten abgreifen können. Dazu legen wir einen im Originalprogramm nicht vorkommenden Parameter an für den wir einen Zeitpunkt "AT SELECTION-SCREEN on neuer_parameter" definieren.
Zu diesem neuen Zeitpunkt wird das Selektionsbild ausgelesen, ins Memory exportiert und dann via "LEAVE PROGRAM" zurück ins rufende Programm gesprungen wo dann die Daten des Selektionsbilds vorhanden sind.
Der neue Parameter wird ganz am Ende des Originalselektionsbildes eingeschleust ( no-display damit der User nicht verwirrt wird ), so dass alle SelScreenprozesse vor AT SELECTION-SCREEN durchlaufen worden sind.
Nachteil. Der Zeitpunkt "AT SELECTION-SCREEN" des Originalprogramms wird leider nicht mehr durchlaufen, so dass dort eingebaute Prüfungen nicht mehr ziehen. Aber evtl. ist das ja zu verschmerzen.
Hier nun der Aufbau des Programms. Nur die 1. Zeile ist dynamisch - dort bitte den Namen des Originalprogramms einsetzen - der Rest ist konstant und könnte auch via Include eingebaut werden, so dass deine Spezialkopie letztlich nur aus 2 Includeanweisungen bestehen müsste.
Code: Alles auswählen.
INCLUDE balvst01.
PARAMETERS: %%tricky NO-DISPLAY.
DATA: %%gt_rsparams TYPE rsparams_tt.
AT SELECTION-SCREEN ON %%tricky.
CHECK sy-ucomm = 'ONLI'.
CALL FUNCTION 'RS_REFRESH_FROM_SELECTOPTIONS'
EXPORTING
curr_report = sy-repid
TABLES
selection_table = %%gt_rsparams
EXCEPTIONS
not_found = 1
no_report = 2
OTHERS = 3.
IF sy-subrc = 0.
EXPORT %%gt_rsparams TO MEMORY ID '%%GT_RSPARAMS'.
ENDIF.
LEAVE PROGRAM.Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
a-dead-trousers
Beitrag
von a-dead-trousers (Top Expert / 4485 / 231 /
1205
)
»
Den Trick kannte ich bereits.
Wäre natürlich ein gangbarer Weg, aber ich müsste dann jeden Report für die Spezial Ausführung ersmal vorbereiten.
Ich such aber nach etwas das Out-Of-The-Box funktioniert.
Im Moment experimentiere ich gerade mit einer Erweiterungs-Implementierung (neues Badi-Konzept in Basis 7.0) im Programm RSDBRUNT.
Damit könnte ich meinen Code automatisch in jeden Selektions-Bildschirm "einschleusen" ohne diesen zu modifizieren.
Aber das implizite Erweitern eines Programms ist im Kern fast mit einer Standard-Änderung gleichzusetzen... Und das noch dazu bei RSDBRUNT.
Tja, was wäre das Leben ohne Gefahr
Soll aber nicht heißen, dass ich nicht auch weiterhin noch andere Vorschläge suche.
lg ADT
Wäre natürlich ein gangbarer Weg, aber ich müsste dann jeden Report für die Spezial Ausführung ersmal vorbereiten.
Ich such aber nach etwas das Out-Of-The-Box funktioniert.
Im Moment experimentiere ich gerade mit einer Erweiterungs-Implementierung (neues Badi-Konzept in Basis 7.0) im Programm RSDBRUNT.
Damit könnte ich meinen Code automatisch in jeden Selektions-Bildschirm "einschleusen" ohne diesen zu modifizieren.
Aber das implizite Erweitern eines Programms ist im Kern fast mit einer Standard-Änderung gleichzusetzen... Und das noch dazu bei RSDBRUNT.
Tja, was wäre das Leben ohne Gefahr
Soll aber nicht heißen, dass ich nicht auch weiterhin noch andere Vorschläge suche.
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 black_adept (Top Expert / 4159 / 136 /
960
)
»
Out-Of-The-Box geht mit "INSERT REPORT" und "GENERATE REPORT"
P.S. Das einzufügende Coding in den Include auslagern.
P.P.S. Der Vorschlag vorhin mit "no-display" funktioniert nicht - dann wird "AT.... on..." nicht prozessiert.
Code: Alles auswählen.
*&---------------------------------------------------------------------*
*& Form GET_DYNPVALUES
*&---------------------------------------------------------------------*
FORM get_dynpvalues USING p_progname TYPE syrepid
CHANGING pt_rsparams TYPE rsparams_tt.
DATA: lt_source TYPE abapsource_t,
tmp_reportname TYPE syrepid VALUE 'ZGET_SELSCREENDATA_TMP_PROG'.
APPEND 'INCLUDE #1.' TO lt_source.
APPEND 'INCLUDE zget_selscreendata_tricky.' TO lt_source.
REPLACE '#1' IN TABLE lt_source WITH p_progname.
INSERT REPORT tmp_reportname FROM lt_source.
CHECK sy-subrc = 0.
GENERATE REPORT tmp_reportname.
CHECK sy-subrc = 0.
FREE MEMORY ID '%%GT_RSPARAMS'.
* Das hier muss vor dem Aufruf dynamisch generiert werden.
SUBMIT (tmp_reportname) VIA SELECTION-SCREEN AND RETURN.
IMPORT %%gt_rsparams FROM MEMORY ID '%%GT_RSPARAMS'.
ENDFORM. " GET_DYNPVALUESP.P.S. Der Vorschlag vorhin mit "no-display" funktioniert nicht - dann wird "AT.... on..." nicht prozessiert.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
a-dead-trousers
Beitrag
von black_adept (Top Expert / 4159 / 136 /
960
)
»
Und noch ein Nachtrag.
Aus Sicherheits- und Performancegründen würde ich den Generierungspart aus der obigen Routine nehmen und mir ein Miniprogramm basteln, welches einen Sack voll Programmnamen als Parameter aufnimmt und zu jedem dieser Programm das 2-Zeilige Begleitprogramm generiert, wobei ich dann irgendwie mir merken muss, wie das jeweils zugehörige Begleitprogramm heißt ( eigene Tabelle oder Ableitungsregel aus Programmnamen zu Begleitprogrammnamen ).
Dann all diese Begleitprogramme auf dem Entwicklungssystem anlegen und dann transportieren und dann aus deinem Rahmenprogramm zum SelScreen auslesen die nun existierenden Begleitprogramme aufrufen.
Aus Sicherheits- und Performancegründen würde ich den Generierungspart aus der obigen Routine nehmen und mir ein Miniprogramm basteln, welches einen Sack voll Programmnamen als Parameter aufnimmt und zu jedem dieser Programm das 2-Zeilige Begleitprogramm generiert, wobei ich dann irgendwie mir merken muss, wie das jeweils zugehörige Begleitprogramm heißt ( eigene Tabelle oder Ableitungsregel aus Programmnamen zu Begleitprogrammnamen ).
Dann all diese Begleitprogramme auf dem Entwicklungssystem anlegen und dann transportieren und dann aus deinem Rahmenprogramm zum SelScreen auslesen die nun existierenden Begleitprogramme aufrufen.
Hi,
vergesst aber nicht daß die 'RS_*' Bausteine in der RSPARAMS Struktur die Parameter / Selektionswerte
auf 45 Bytes beschränken. Ist ein Parameter / Selektionswert länger - wird auf 45 Bytes gekürzt !
Das Problem hatte ich auch bei einer Varianten Auswertung, so daß ich mich direkt mit den VARI* s herumschlagen musste.
/Edwin
vergesst aber nicht daß die 'RS_*' Bausteine in der RSPARAMS Struktur die Parameter / Selektionswerte
auf 45 Bytes beschränken. Ist ein Parameter / Selektionswert länger - wird auf 45 Bytes gekürzt !
Das Problem hatte ich auch bei einer Varianten Auswertung, so daß ich mich direkt mit den VARI* s herumschlagen musste.
/Edwin
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
5356
Views
Views
2
Antw.
Antw.
2163
Views
Views
5
Antw.
Antw.
5038
Views
Views
SAP Web Inhalte und Internet Explorer 7
von Kaiwalker » 22.11.2006 08:20 • Verfasst in SAP - Allgemeines
von Kaiwalker » 22.11.2006 08:20 • Verfasst in SAP - Allgemeines
9
Antw.
Antw.
4016
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
Bestellungen -> neue Freigabestrategie -> Tabelle KSSK 032 Eintrag wird nicht transportiert
vor 25 Minuten von Romaniac 8 / 6751
vor 25 Minuten von Romaniac 8 / 6751
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
Bestellungen -> neue Freigabestrategie -> Tabelle KSSK 032 Eintrag wird nicht transportiert
vor 25 Minuten von Romaniac 8 / 6751
vor 25 Minuten von Romaniac 8 / 6751
Unbeantwortete Forenbeiträge
Custom logic - Feld wieder initialisieren (BADI CRMS4_SERV_CUST_H_MODIFY)
vor 4 Wochen von JanR 1 / 109752
vor 4 Wochen von JanR 1 / 109752
F6862 - Stücklistenpositionen Massenhinzufügen ohne Änderungsnummer
April 2026 von Radinator 1 / 172923
April 2026 von Radinator 1 / 172923