Speichern von Eingabe des Selektionscreens
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Ich habe einen Report mit Selektionsscreen. Dieser ist nun so programmiert, dass nach der Auswahl ein Dynpro prozessiert wird. Verlässt man dieses Dynpro, so wird der Report bzw. die Transaktion neu gestartet (ist aus irgendeinem Grund so programmiert). Im Ergebnis sind alle Benutzereingaben weg. Vom Kunden ist nun gewünscht, das diese Eingaben erhalten bleiben.
Die saubere Variante wäre, hierfür Benutzerparameter anzulegen und diese an das Selektionsfeld zu binden. Jedoch sind es sehr viele Parameter und am Ende auch 3 Reports die angepasst werden müssen.
Also hatte ich die Idee im START-OF-SELECTION via FuBa RS_REFRESH_FROM_SELECTOPTIONS diese Werte auszulesen pro Feld per SET PARAMETER wegzuschreiben. Dieses dann im INITIALIZATION wieder via GET zu lesen.
Das klappt aber nicht für Select-Options, welche mehre Zeilen als Eingabewerte haben.
Nun war meine Plan, dies über Shared Memory Objects zu machen. Dort wollte ich die gesamte Tabelle aus Fuba RS_REFRESH_FROM_SELECTOPTIONS ablegen.
FRAGE: Das Shared Memory ist doch benutzerübergreifend - oder?
Würde also auch nicht klappte. Oder kann man die Daten im Shared Memory pro Benutzer ablegen?
Was hätte ich noch für eine Möglichkeit, den Wunsch des Kunde zu erfüllen?
Die saubere Variante wäre, hierfür Benutzerparameter anzulegen und diese an das Selektionsfeld zu binden. Jedoch sind es sehr viele Parameter und am Ende auch 3 Reports die angepasst werden müssen.
Also hatte ich die Idee im START-OF-SELECTION via FuBa RS_REFRESH_FROM_SELECTOPTIONS diese Werte auszulesen pro Feld per SET PARAMETER wegzuschreiben. Dieses dann im INITIALIZATION wieder via GET zu lesen.
Das klappt aber nicht für Select-Options, welche mehre Zeilen als Eingabewerte haben.
Nun war meine Plan, dies über Shared Memory Objects zu machen. Dort wollte ich die gesamte Tabelle aus Fuba RS_REFRESH_FROM_SELECTOPTIONS ablegen.
FRAGE: Das Shared Memory ist doch benutzerübergreifend - oder?
Würde also auch nicht klappte. Oder kann man die Daten im Shared Memory pro Benutzer ablegen?
Was hätte ich noch für eine Möglichkeit, den Wunsch des Kunde zu erfüllen?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Die saubere Variante wäre, den Neustart der Transaktion zu entfernen.
Das, was du möchtest, ist das Standardverhalten eines Reports!
Mit Benutzerparametern kommst du nicht weit, da du so keine Select-Options speichern kannst.
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Hallo msfox,
du hast doch schon alles parat um das zu bewerkstellligen. Der FuBa RS_REFRESH_FROM_SELECTOPTIONS gibt dir all deine Informationen in einer Tabelle vom Typ "RSPARAMS" zurück. Und zufälligerweise besitzt der SUBMIT-Befehl einen Zusatz "WITH SELECTION TABLE" ( Doku hier) der genau so einen Tabellentyp erwartet.
Falls der Neustart des Programm über "SUBMIT" erfolgt brauchst du das nur mitzugeben. Wenn es über "CALL TRANSACTION" erfolgt musst du dich eines kleinen Tricks bedienen: Zunächst stellst du die RSPARAMS-Tabelle mittels "EXPORT TO MEMORY ID " ins globale ( nicht shared ) Memory ( als ID verwende ich in so einem Fall immer den Reportnamen ). Und in das Programm selber baust du zum Zeitpunkt "INITIALIZATION" ein IMPORT FROM MEMORY ein und wenn da etwas gefunden wird machst du dort dann den SUBMIT auf sich selbst mit den Parametern.
P.S. Es empfiehlt sich in letzerem Fall nach dem IMPORT FROM MEMORY dieses explizit zu löschen um nicht in eine amüsante Endlosschleife zu geraten.
du hast doch schon alles parat um das zu bewerkstellligen. Der FuBa RS_REFRESH_FROM_SELECTOPTIONS gibt dir all deine Informationen in einer Tabelle vom Typ "RSPARAMS" zurück. Und zufälligerweise besitzt der SUBMIT-Befehl einen Zusatz "WITH SELECTION TABLE" ( Doku hier) der genau so einen Tabellentyp erwartet.
Falls der Neustart des Programm über "SUBMIT" erfolgt brauchst du das nur mitzugeben. Wenn es über "CALL TRANSACTION" erfolgt musst du dich eines kleinen Tricks bedienen: Zunächst stellst du die RSPARAMS-Tabelle mittels "EXPORT TO MEMORY ID " ins globale ( nicht shared ) Memory ( als ID verwende ich in so einem Fall immer den Reportnamen ). Und in das Programm selber baust du zum Zeitpunkt "INITIALIZATION" ein IMPORT FROM MEMORY ein und wenn da etwas gefunden wird machst du dort dann den SUBMIT auf sich selbst mit den Parametern.
P.S. Es empfiehlt sich in letzerem Fall nach dem IMPORT FROM MEMORY dieses explizit zu löschen um nicht in eine amüsante Endlosschleife zu geraten.
Danke für die Infos. Ich bin leider nicht Dynpro-Entwickler um die Tricks zu kennen. Eher Webdynpro. Trotzdem hatte ich mit dem EXPORT und IMPORT TO MEMORY schon probiert. Wenn aber die Transaktion neu gestartet, was bei einem LEAVE TO TRANSACTION passiert, so ist die alte Session weg und der IMPORT im INITIALIZATION liefert nix.black_adept hat geschrieben: ↑21.08.2019 20:07Zunächst stellst du die RSPARAMS-Tabelle mittels "EXPORT TO MEMORY ID " ins globale ( nicht shared ) Memory ( als ID verwende ich in so einem Fall immer den Reportnamen ). Und in das Programm selber baust du zum Zeitpunkt "INITIALIZATION" ein IMPORT FROM MEMORY ein und wenn da etwas gefunden wird machst du dort dann den SUBMIT auf sich selbst mit den Parametern.
Ander Varianten:
Es gibt die Funktion "Syste->Benutzervorgaben->Daten halten". Laut Doku aktiviert man diese Funktion mit SET HOLD DATA ON. Das habe ich im INITIALIZATION eingebaut. Das schein rudimentär zu funktionieren. Nicht immer sind die gehaltenen Daten nach einem LEAVE TO TRANSACTION noch da.
Wenn ich mir ab den Code bei meinem Report so anschaue, scheint die Funktion so gewollt zu sein, dass die Daten verloren gehen.
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Das ist falsch. Export to Memory geht auch über Transaktionsgrenzen hinaus
Seite 1 von 1
Vergleichbare Themen
8
Antw.
Antw.
3226
Views
Views
1
Antw.
Antw.
4677
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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 3 Tagen von a-dead-trousers 5 / 1405
vor 3 Tagen von a-dead-trousers 5 / 1405
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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 3 Tagen von a-dead-trousers 5 / 1405
vor 3 Tagen von a-dead-trousers 5 / 1405