interne Tabelle zwischen Reports übergeben
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
Hallo zusammen,
ich habe einen Report A, welcher über submit einen anderen Report B aufruft. In Report B können verschiedene Situationen auftreten, die ich Report A als Information zurückgeben möchte. Wie kann ich mehrere Werte, in diesem Fall Texte, die Report A als Info ausgeben soll, von Report B an Report A übergeben. Für einzelne Werte wird bereits export/import to memory id verwendet. Ich möchte jetzt aber quasi eine Möglichkeit haben, um eine interne Tabelle mit einer vorher unbestimmten Anzahl an Einträgen zu übergeben.
Kann mir da jemand weiter helfen?
Aba
ich habe einen Report A, welcher über submit einen anderen Report B aufruft. In Report B können verschiedene Situationen auftreten, die ich Report A als Information zurückgeben möchte. Wie kann ich mehrere Werte, in diesem Fall Texte, die Report A als Info ausgeben soll, von Report B an Report A übergeben. Für einzelne Werte wird bereits export/import to memory id verwendet. Ich möchte jetzt aber quasi eine Möglichkeit haben, um eine interne Tabelle mit einer vorher unbestimmten Anzahl an Einträgen zu übergeben.
Kann mir da jemand weiter helfen?
Aba
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 / 4399 / 223 /
1182
)
»
Auf demselben Weg:
Code: Alles auswählen.
EXPORT
var1 FROM ld_var1
var2 FROM ld_var2
var3 FROM lt_var3
TO MEMORY ID 'TEMP'.
...
IMPORT
var1 TO ld_var4
var2 TO ld_var5
var3 TO lt_var6
FROM MEMORY ID 'TEMP'.
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
Rein technisch kann man auch mit einem Shared Memory arbeiten. Aber das ist dann glaube ich mit Kanonen auf Spatzen geschossen.
Beim Import/Export würde ich die MemoryID's in Constanten packen. Dann kann man via Verwendungsnachweis leichter prüfen, wo der Import/Export gerufen wird.
Auch würde ich die Variablen in beiden Reports gleich benennen. Das vereinfacht so einiges. Alles schon erlebt und immer wieder verzweifelt. :).
Beim Import/Export würde ich die MemoryID's in Constanten packen. Dann kann man via Verwendungsnachweis leichter prüfen, wo der Import/Export gerufen wird.
Auch würde ich die Variablen in beiden Reports gleich benennen. Das vereinfacht so einiges. Alles schon erlebt und immer wieder verzweifelt. :).
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Daten übergeben mit dem Shared Memory ist schon eine üble Krücke. Ich räume ein, dass es in diesem Fall nicht anders geht, sofern Selektionsparameter nicht ausreichen und man nicht extra eine Datenbanktabelle als Übergabetabelle anlegen möchte (was auch eine Option wäre, und nicht die schlechteste). Aber da sollte dann auf beiden Seiten (also im sendenden und im empfangenden) Report an dem Selektionsparameter ein ausreichend ausführlicher Kommentartext stehen, in dem genau erläutert wird, wo die Werte hingehen bzw. herkommen. Das halte ich für mehr wert als die Nutzung von Konstanten.
Wenn die Memory ID ausreichend speziell ist, kann man sich auch mit der Transaktion EWK1 retten. Die ID sollte dann natürlich nicht TEMP heißen (sowas wird es in vielen Programmen geben) oder den Namen eines ABAP-Schlüsselwortes oder sonst verbreiteten Wortes haben.Beim Import/Export würde ich die MemoryID's in Constanten packen. Dann kann man via Verwendungsnachweis leichter prüfen, wo der Import/Export gerufen wird.
Auch würde ich die Variablen in beiden Reports gleich benennen. Das vereinfacht so einiges. Alles schon erlebt und immer wieder verzweifelt. :).
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Hallo aba,
wenn ihr eh schon Daten über MemoryIds übergebt gibt es keinen Grund jetzt umzusteigen sondern ihr solltet so zu verfahren wie von a-d-t vorgeschlagen.
Ich persönlich bin aber keine großer Freund dieser Art der Datenübergabe in ein eigenes Programm, zumal es auch die Möglichkeit gibt Tabellen oder überhaupt ziemlich komplexe Datenstrukturen beim Submit in ein anderes Programm zu übergeben wenn man auf MEMORY-IDs oder Shared Memory verzichten möchte.
Beispiel: Prog1 liest eine Tabelle, Prog 2 gibt die Tabelle aus
Prog1 - liest die Daten
Prog2 - Zeigt die Daten aus Prog1 an - Daten werden im Submit über Parameter übergeben
wenn ihr eh schon Daten über MemoryIds übergebt gibt es keinen Grund jetzt umzusteigen sondern ihr solltet so zu verfahren wie von a-d-t vorgeschlagen.
Ich persönlich bin aber keine großer Freund dieser Art der Datenübergabe in ein eigenes Programm, zumal es auch die Möglichkeit gibt Tabellen oder überhaupt ziemlich komplexe Datenstrukturen beim Submit in ein anderes Programm zu übergeben wenn man auf MEMORY-IDs oder Shared Memory verzichten möchte.
Beispiel: Prog1 liest eine Tabelle, Prog 2 gibt die Tabelle aus
Prog1 - liest die Daten
Code: Alles auswählen.
REPORT zprog_source.
DATA: gv_xml TYPE string.
SELECT *
FROM t005
INTO TABLE @DATA(gt_data).
CALL TRANSFORMATION id
SOURCE data = gt_data
RESULT XML gv_xml.
SUBMIT zprog_called_with_submit WITH p_data = gv_xml AND RETURN.
WRITE 'Ende'.Code: Alles auswählen.
REPORT zprog_called_with_submit.
DATA: gt_t005 TYPE STANDARD TABLE OF t005 WITH NON-UNIQUE DEFAULT KEY.
PARAMETERS: p_data TYPE string NO-DISPLAY.
CALL TRANSFORMATION id
SOURCE XML p_data
RESULT data = gt_t005.
cl_salv_table=>factory( IMPORTING
r_salv_table = DATA(go_salv)
CHANGING
t_table = gt_t005 ).
go_salv->display( ).Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 3):
a-dead-trousers • DeathAndPain • deejey
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Netter Kunstgriff. Aber "WITH NON-UNIQUE DEFAULT KEY", wer braucht denn sowas, zumal bei einer Standardtabelle? Von dem Promille der Fälle abgesehen, bei dem man was mit COLLECT etc. machen möchte, ist das doch leerer Overhead. Ich schreibe bei Gelegenheiten wie diesen gerne explizit WITH EMPTY KEY in die Deklaration. Das ist eine klare Ansage an den Leser - und nebenbei spare ich Geier noch ein paar Bytes ein. 😎
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Deswegen:
https://help.sap.com/doc/saphelp_tm92/9 ... cache=true
Man kann die z.B. dann nicht als RETURN-Parameter in Methoden verwenden.
Daher hab ich mir angewöhnt schon von Haus aus immer den "WITH DEFAULT KEY" mit anzugeben.
https://help.sap.com/doc/saphelp_tm92/9 ... cache=true
Man kann die z.B. dann nicht als RETURN-Parameter in Methoden verwenden.
Daher hab ich mir angewöhnt schon von Haus aus immer den "WITH DEFAULT KEY" mit anzugeben.
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 DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Was willst Du damit sagen? Eine mit EMPTY KEY deklarierte Tabelle ist nicht generisch!
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
So wie oben beschrieben. Wenn du Angst hast kannst du die Daten ja noch zippen bzw. im empfangenden Programm entzippen. Aber Speicher ist Speicher - und ob du die Tabelle nun im MEMORIES-Bereich ablegst oder wo auch immer SAP die PARAMETER-Daten von Strings ablegt ( Heap? ) scheint mir zunächst egal solange SAP nicht intern irgendwo nur bei einem der Verfahren selbst eine Komprimierung vornimmt oder Daten mehrfach vorhält.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
qyurryus
Beitrag
von bapimueller (Specialist / 110 / 9 /
1
)
»
Hallo zusammen,
das Problem ist zwar nicht mehr ganz aktuell, aber ich hatte vor kurzem auch ein ähnliches Problem. Im SDN habe ich 2 interessante Blog Beiträge gefunden, welche sehr anschaulich die Verwendung von shared memory klassen und Objekte erklären.
https://archive.sap.com/kmuuid2/307d791 ... bjects.pdf
https://blogs.sap.com/2020/04/28/shared ... -programs/#
Vielleicht hilft es dem ein oder anderen ja.
Viele Grüße,
Thomas
das Problem ist zwar nicht mehr ganz aktuell, aber ich hatte vor kurzem auch ein ähnliches Problem. Im SDN habe ich 2 interessante Blog Beiträge gefunden, welche sehr anschaulich die Verwendung von shared memory klassen und Objekte erklären.
https://archive.sap.com/kmuuid2/307d791 ... bjects.pdf
https://blogs.sap.com/2020/04/28/shared ... -programs/#
Vielleicht hilft es dem ein oder anderen ja.
Viele Grüße,
Thomas
Folgende Benutzer bedankten sich beim Autor bapimueller für den Beitrag:
IHe
Thomas Müller
SAP Beratung
M: +49 (0) 173 / 870 39 31
T: +49 (0) 6228 / 924 560
F: +49 (0) 6228 / 924 559
SAP Beratung
M: +49 (0) 173 / 870 39 31
T: +49 (0) 6228 / 924 560
F: +49 (0) 6228 / 924 559
Seite 1 von 1
Vergleichbare Themen
5
Antw.
Antw.
2138
Views
Views
Inhalt interne Tabelle an andere interne Tabelle übergeben
von L0w-RiDer » 30.01.2020 16:28 • Verfasst in ABAP® für Anfänger
von L0w-RiDer » 30.01.2020 16:28 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
3997
Views
Views
interne Tabelle als Parameter zu übergeben?
von oo » 25.05.2006 10:46 • Verfasst in Web-Dynpro, BSP + BHTML
von oo » 25.05.2006 10:46 • Verfasst in Web-Dynpro, BSP + BHTML
16
Antw.
Antw.
5494
Views
Views
interne tabelle per rfc übergeben und annehmen
von theuser » 12.06.2014 14:31 • Verfasst in ABAP® für Anfänger
von theuser » 12.06.2014 14:31 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
6423
Views
Views
1
Antw.
Antw.
4178
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.