Frage zu Call Screen/Aufruf Zwischendialog/Dynpro

[Christa4829]

Guten morgen,
ich erweitere gerade Standardcoding in der Funktionsgruppe RHVS. Die Funktionsgruppe "kapselt" Funktionalitäten des Veranstaltungsmanagement/Weiterbildung.

Ich habe ein simples Problem.
Folgendes Szenario.
1. In o.g. Funktionsgruppe gibt es ein Unterprogramm/Form namens EMAIL.
2. In dieser Form wird der Report RHMAIL10 aufgerufen um Mails zu versenden (An Seminarteilnehmer)
Der Aufruf ist wie folgt:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1.     perform send_mail(rhmail10)
2.             tables mail_text
3.                    mail_parm
4.                    mail_parb
5.                    mail_recv
6.             using  mail_attr
7.                    sy-uname
8.                    mail_title
9.                    e_subrc.          "(error: 01-10)
10.  

GeSHi ©

3. Das Programm rhmail10 und dessen routine send_mail sind modifiziert. Alles bisher noch ok.
4. Neue Anforderung: Vorm letztendlichen senden der Mail in RHMAIL10 soll ein Dynpro zur Datenerfassung gerufen werden. Deshalb habe ich auch in RHMAIL10 ein neuen dynpro angelegt und es per call screen aufgerufen. Leider bedankt sich das System aber mit einem Dump.
5. Mir ist aufgefallen, dass in der Anweisung CALL SCREEN in RHMAIL10 das Dynpro aus dem rufenden Programm aufgerufen wird. Also habe ich das Dynpro in der Funktionsgruppe RHVS angelegt und es funktioniert. (Bringt aber nun andere Baustellen mit ins Boot, Sinleton, Datenbeschaffung zwischen den Programmen, etc.)

Nun zur Frage. Warum ist das so? Wie kann ich RHMAIL10 sagen, dass es sein eigenes Dynpro rufen soll?
Vielen Dank

[Jonny2227]

Sali,

kannst du das nicht in einer Implementierung zum BADI - HRTEM_CORR_NOTIF_REQ - erledigen - was du da vor hast.
Das Interface wird ja in der Routine aufgerufen - müsstest also gar nichts modifizieren vielleicht !

Gruss Jens

... übrigens wird im der Funktionsgrupper nur die Formroutine send_mail aus dem Programm rhmail10 aufgerufen - daher hat die FUGR den Lead weiterhin im Programmablauf ...

[Christa4829]

Salut,
danke fürs beantworten.
was macht denn das Badi genau? Kannste dazu was sagen? Also mit BADI Technologie kenne ich mich aus, aber ich habe im RHMAIL10 den kompletten emailversand ausgeknippst und über BCS in OO realisiert, da ich Dateianhänge relisiert und die Empfängerliste erwertert habe. Natürlich ist es imm schöner Modifikationsfrei zu sein, aber das ist jetzt eine andere Fragestelle. Nichts desto trotz müsste ich dann dort den CALL Screen aufrufen und die Problematik wäre die gleiche. Das nehme ich zumindest sehr stark an.
Gruss
Timo

[Jonny2227]

Sali,

nun dazu hättest du aber auch nicht unbedingt modifizieren müssen - mit einem modofikationsfreien Enhancement - am Anfang der Formroutine - hättest du auch dein ganzes Coding plazieren können und dann mit Exit die Routine verlassen.
Nun und deine Erweiterung des Anhanges etc. hättest du nicht dem FUBA - send... - mitgeben können ?
Nun im BADI könntest du ja per submit and return dein eigenes Programm mit dem Dynpro aufrufen und die Daten übers Memory austauschen - aber in diesem BADI ist eigentlich nur die Empfangsbestätigung etc. vorgesehen zu ändern.
Also was willst du für Eingaben abfragen ? Oder packe dein ganzes Coding in einen FUBA oder Report und den rufst du dann auf und sendest dein Dynpro.

Gruss Jens

[Christa4829]

Salut!
zu dienem Vorschlag mit dem Fuba. Idee ok. Ich hab es ähnlich gelöst, nämlich über ABAP OO und ein Singleton Pattern.
1. Aufruf TA PP40 - unterprogramm email
2. RHMAIL10 unterprogramm send_mail. Dann schieb ich dort die ganzen ermittelten daten in eine klasse
3. aufruf call screen ausserhalb von RHMAIL10. Dort lese ich dann über die Klasse die mitgegebenen werte aus. Prinzipiell nichts anderes als ein Fuba.

Ich möchte mir aber gerne das ganze Datenhin- und hergeschiebe sparen. Das könnte ich, wenn ich das Dynpro zur Datenerfassung direkt in RHMAIL10 aufrufen könnte.

Mit Memory auslesen kenne ich mich leider garnicht aus.

Zu deiner Aussage: ... übrigens wird im der Funktionsgrupper nur die Formroutine send_mail aus dem Programm rhmail10 aufgerufen - daher hat die FUGR den Lead weiterhin im Programmablauf ...

Ah ok. Ich dachte der Lead geht an das RHMAIL10 Programm. Schade das es nicht so ist

[Jonny2227]

Sali,

wenn du nun in deiner Klasse einen editierbaren ALV (mit Klasse CL_SALV_Table) benutzt - wenn deine Daten in Tabellenform daher kommen sollten oder so - dann braucht es kein Dynpro etc. und du hast die daten gleich in deiner Klasse ?!

Gruss Jens

[Christa4829]

Salut,
ich bin gerade dabei den OO Ansatz zu verwerfen FUBA innerhalb RHVS zu nutzen. Ich denke ich bin nah an der Lösung.
Merci...ich melde mich nochmal wenn meine Frage beantwortet.

[Jonny2227]

Sali,

den OO Ansatz musst du doch dann gar nicht komplett verwerfen - kapsle einfach den Aufruf in den FUBA - dann hast du den bisherigen Aufwand nicht für umsonst und die Daten kannst du fein über das FUBA Interface austauschen !

Gruss Jens

[Christa4829]

Salut,
danke Jens! Hab ich auch gemacht. GEht mir im wesentlichen um die Schnittstelle beim Fuba..ist der sauberste Ansatz denke ich.