export to Memory ID
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.Ich wüßte keinen Grund, das in einer reinen kundeneigenen Entwicklung zu verwenden.4byte hat geschrieben: Gibt es jemanden, der das für seine (kunden)eigenen Porgramme verwendet ??
Ich kenne auch keine in meinem Umfeld.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Doch, dann liegt der kundeneigene FB ja ganz unten in der Aufrufhierarchie, so dass man den von mir beschriebenen Weg des Ausbruchs aus der Sandbox gehen und direkt in eine Variable des kundeneigenen Reports schreiben kann. Das ist zwar auch nicht schön, aber doch zumindest ein bisschen besser, da man dann im Code den Report angibt, zu dem die Variable gehört, so dass der Leser beim Export sofort sieht, wo der Wert denn hingehen soll (anstatt dass dieser einfach in die Cloud geschossen wird, um dann irgendwann mal von irgendwem irgendwo gelesen zu werden). Beim aufrufenden Report ist dann natürlich trotzdem ein passender Codekommentar notwendig, der den zusätzlichen, nicht im Interface deklarierten "Exportparameter" der gerufenen SAP-Methode erläutert.A6272 hat geschrieben:Wenn ein Kundeneigener Report SAP Standard Methoden aufruft, welcher wiederum dynamisch kundeneigene Funktionsbausteine aufruft, dann geht es halt nicht anders, um Informationen an den Aufrufer zurückzuübermitteln.
Wie gesagt, auch nicht wirklich schön, aber IMHO allemal besser als der Weg über das MEMORY.
Oftmals stehen die notwendigen Daten aber nur lokal zur Verfügung. Dann hilft der Assign über die Aufrufhierarchie nicht.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Ich weiß, aber speziell in dem von A6272 geschilderten Fall geht es.
Es werden dynamisch kundeneigene Funktionsbausteine aufgerufen, d.h. ich kann zwar per SAP-Customizing die möglichen FB pro Aufruf ermitteln, aber die Kombination ist unterschiedlich und zusätzlich abhängig vom Ergebnis. Es werden bei einem SAP Methodenaufruf 1 oder 2 FB prozessiert. Ob der 2. FB aufgerufen wird ist unbekannt.DeathAndPain hat geschrieben: Doch, dann liegt der kundeneigene FB ja ganz unten in der Aufrufhierarchie, so dass man den von mir beschriebenen Weg ...
Geht das dann immer noch?
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Das ist doch sch...egal. So, wie ich Dich verstanden habe, willst Du ja aus Deinem FB (der möglicherweise aufgerufen wird) etwas an Deinen aufrufenden Report zurückliefern. Da gibt es doch nur zwei Möglichkeiten: Entweder Dein FB wird aufgerufen, dann kann er sich eine Variable des rufenden Reports assignen
und ihren Inhalt manipulieren, oder er wird halt nicht aufgerufen, dann macht er gar nichts. Der andere FB von Dir genauso.
Dein aufrufender Report ruft die SAP-Methode und schaut sich einfach hinterher an, was er in seinen (als Interface zu den FBs gedachten, aber einfach per DATA deklarierten) Variablen drinzustehen hat.
Code: Alles auswählen.
DATA S(50) TYPE C.
S = '(RUFENDERREPORT)INTERFACEFELD'.
ASSIGN (S) TO <INTERFACEFELD>. " Dieses Feldsymbol zeigt jetzt auf die Variable des rufenden Reports.Dein aufrufender Report ruft die SAP-Methode und schaut sich einfach hinterher an, was er in seinen (als Interface zu den FBs gedachten, aber einfach per DATA deklarierten) Variablen drinzustehen hat.
Vergleichbare Themen
12
Antw.
Antw.
6738
Views
Views
8
Antw.
Antw.
3246
Views
Views
4
Antw.
Antw.
16905
Views
Views
8
Antw.
Antw.
7170
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.