ich habe folgendes Problem und würde gerne Euch um Hilfe / Tipps bitten:
Eine eigene Transaktion "A" wird gestartet. Innerhalb des Aufrufs findet der Aufruf einer SAP-Transaktion "B" statt. Mit/Nach erfolgreicher Bearbeitung und Sicherung in Transaktion "B" wird wieder in Transaktion A rückgekehrt und hier einer abermalige Speicherung durchgeführt.
Problem:
Ich habe gemeinsame Daten, die ich in Transaktion A und Transaktion B benötige. Da es sich hierbei um zwei unterschiedliche Transaktionen handelt, die in unterschiedlichen Laufzeitumgebungen aufgerufen werden, sind meine erstellen Klassen und Steuer-Variabeln etc. von Transaktion A in Transaktion B nicht (mehr) verfügbar - und umgekehrt.
Frage: Gibt es einen Weg, Objekte zu erstellen, die in Transaktion A und(!) B verfügbar sind?
Ich persönlich bin auf Shared Objects gestoßen: Jedoch ist diese Methode nur für minimale Schreibzugriffe gedacht (Sperrkonzept) und kommt somit nicht in Frage.
Kennt Ihr noch einen Weg?
entweder du machst deine Klasse in der SAP TA bekannt - siehe Class definition load etc. oder du benutzt einen Dirty Assign - siehe dazu Tricktresor.de
1) Dirty-Assign arbeitet (anscheinend?) transaktionsübergreifend nicht. Auf Daten von Transaktion A kann von Transaktion B nicht zugriffen werden. Des Weiteren scheint ein Assign auf Klassen-Referencen nicht möglich zu sein.
2) Modifikation am SAP-Standard können nicht durchgeführt werden.
Zur weiteren Info: Es handelt sich um die SAP-Transaktionen MM01 und MM02.
also mit dem Dirty Assign kannst du schon auf die Klassen reference Variable zugreifen - das klappt .
Wenn keine modifikation am Standard erfolgen soll - warum willst du dann die daten aus dem rufenden Programm dort haben bzw. was genau willst du eigentlich erreichen mit dieser ganzen Aktion des datenaustausch etc. ?
ich nutze mehrere BAdIs in den MM-Transaktionen.
Bspw. IF_EX_BADI_MATERIAL_CHECK.
Hier soll bei Material-Speicherung eine Prüfung durchgeführt werden.
Die Rahmendaten dieser Prüfung werden jedoch im Vorfeld von Transaktion A bestimmt und sollen nun hier "abgegriffen" und verarbeitet werden und teilweise mit anderen Daten auch wieder an Transaktion A zurückgegeben werden.
Das würde das konkrete Anwendungs-Szenario darstellen.
Ja, dieser Weg ist bei einer Vielzahl von Tabellen und Variabeln jedoch nicht wirklich schön... und für Objekte nicht anwendbar.
Andere Möglichkeiten scheint es aber anscheinend nicht zu geben... !?
Deine "Transaktion B" scheint ja das normale Ändern des Materialstamms zu sein. Wenn du nun deine Änderung statt mit "CALL TRANSACTION" mit dem dafür vorgesehen BAPI oder dem Standardmaterialänderungsfuba machst solltest du auch den vorgeschlagenen Weg über "DIRTY ASSIGN" oder über ein globales Funktionsgruppen memory gehen können. Außerdem sollte im userexit/Badi der sy-tcode nocht auf deiner "Transaktion A" liegen, so dass du evtl. auch via Callback-Routine arbeiten kannst. Oder du schaust im CallStack nach, ob dein Programm dort noch drin liegt um einen Callback zu machen.
nochmal Danke für Eure Empfehlungen.
Habe es nun durch einen Import/Export via Memory-ID gelöst. Hier importiere/exportiere ich eine Struktur mit tiefen Strukturen, die ich im Vorfeld über Klassenmethoden aus den jeweiligen Objekten der eigenen Transaktion versorge.
@black_adept:
In der MM-Transaktion läuft ein Dialog-Prozess ab, so dass hier keine Fubas oder BAPIs zur Änderung / Anlage zur Anwendung kommen können.