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 ??
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.
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 ...
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.