Einfaches Dynpro mit Programm verbinden
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.so, danke für all euren Input. Ich habe eine Lösung gefunden die schlanker und besser zu meinem Problem passt, als der gedankliche Weg den ich am Anfang eingeschlagen habe.
https://www.tricktresor.de/blog/radiobu ... ge-felder/
Die Möglichkeit bestimmte Felder einfach auszublenden und somit Wahlmöglichkeiten oder Eingabemöglichkeiten einzuschränken ist perfekt.
https://www.tricktresor.de/blog/radiobu ... ge-felder/
Die Möglichkeit bestimmte Felder einfach auszublenden und somit Wahlmöglichkeiten oder Eingabemöglichkeiten einzuschränken ist perfekt.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathAndPain (Top Expert / 1964 / 261 /
415
)
»
Gleich mehrere:black_adept hat geschrieben:Nenn mal ein einziges Beispiel, wo ein Modulpool flexibler ist als ein Report
- Du willst sofort nach Programmstart im Einstiegsbild ein Table Control mit Werten anzeigen
- Du willst die Optik des Einstiegsbildes frei gestalten. Beispielsweise willst Du ein Materialanzeigeprogramm machen, bei dem Du links ein Feld für die Materialnummer hast, und sobald der Benutzer dort eine Nummer eingegeben hat, werden auf der rechten Seite (desselben Dynpros!) für das betreffende Unternehmen wichtige Detaildaten des Materials übersichtlich dargestellt (ohne dass sie über soundsoviel Unterdynpros verstreut sind, wie man das aus der MM03 kennt).
- Du willst auf dem Einstiegsbild Parameter verwenden, deren Feldnamen länger als nur erbärmliche 8 Zeichen sein sollen.
- Du willst ein Programm schaffen, das die manuelle Pflege von Daten ermöglicht, mit dem also Einzeldaten in das System hinein, statt aus dem System herausgelangen. Sowas wie die MM02. Ich hatte ja zuvor schon gefragt, wie Du eine MM02 als Report programmieren würdest, jedoch keine Antwort bekommen.
- Du willst Dein Einstiegsbild komfortabel mit dem Layout Editor gestalten und Dir nicht den Kopf zermartern, wie Du die von Dir gewünschte Optik mit Befehlen des Selektionsbildes hinbekommen kannst (mit denen man vieles ja auch gar nicht hinbekommen kann)
Betrachten wir es mal andersherum: Der einzige Vorteil eines Reports gegenüber einem Modulpool besteht darin, dass man sehr einfach ein Selektionsbild mit abfragbaren Feldern hinbekommt (neben der heute kaum noch revelanten Einbindungsmöglichkeit der veralteten logischen Datenbanken). In dem Moment, in dem man ein Programm schreibt, das naturgemäß kein "Selektionsbild" benötigt, verliert der Report diesen Vorteil und ist einem Modulpool in jeder Hinsicht unterlegen.
Beeindruckerweise kann man in den allermeisten Programmen einen Selektionsbildschirm gut gebrauchen, weswegen ich auch fast nur Reports schreibe. Ich verliere aber deswegen die Zusammenhänge nicht aus dem Auge und kenne die Fälle, in denen das nicht so ist.
Kürzlich stand ich vor der Anforderung, ein Programm zu schreiben, in das die User listenmäßig Daten eingeben können für Bescheinigungen, die erstellt werden sollen. Ein Excel-Upload war ausdrücklich nicht gewünscht, sondern eine manuelle Einpflegemöglichkeit mit passenden, kontextabhängigen Hilfsfunktionen in den betreffenden Feldern, aber der Reihe nach von oben nach unten runter, ohne sich durch soundsoviel Dynpros hangeln zu müssen. Da habe ich einen Modulpool gemacht. Die Einstiegstransaktion springt in ein großes, eingagebereites Table Control, wo die Sachbearbeiter ihre Werte von links nach rechts runterschreiben können, wobei die in die linken Felder eingegebenen Werte die Suchhilfen in den folgenden Feldern hilfreich beeinflussen.
Zum Schluss schaut der Sachbearbeiter kurz drüber, ist zufrieden und klickt auf "Speichern".
Das kriste mit einem Report nicht sinnvoll hin. Wie gesagt, wenn Du es hinkriegst, dann nur, weil Du durch Tricks den Report so verbiegst, dass er sich so verhält, wie ein Modulpool es von Natur aus machen würde (CALL SCREEN im INITIALIZATION oder solche Scherze).
Ein Report ist ein direkt ausführbares Programm.
Ein Modulpool nur in Verbindung mit einer Transaktion.
Alles, was du beschrieben hast, kannst du mit einem Programm vom Typ "1 - Ausführbares Programm" machen.
Bei Start-Of-Selection kommt dann ein CALL SCREEN und du kannst alles so programmieren, wie bei einem Programm vom Typ "M - Modulpool".
Ein Modulpool nur in Verbindung mit einer Transaktion.
Alles, was du beschrieben hast, kannst du mit einem Programm vom Typ "1 - Ausführbares Programm" machen.
Bei Start-Of-Selection kommt dann ein CALL SCREEN und du kannst alles so programmieren, wie bei einem Programm vom Typ "M - Modulpool".
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag (Insgesamt 2):
a-dead-trousers • black_adept
Beitrag
von DeathAndPain (Top Expert / 1964 / 261 /
415
)
»
Was ist denn das für ein Krampf: Ein Report mit einem leeren Selektionsbild, dann kommt ein START-OF-SELECTION keiner Selektion und dann ein CALL SCREEN in das eigentliche Dynpro. Der ganze Code bis einschließlich des CALL SCREEN ist ein reiner Wasserkopf.
Und wozu? Um keine Transaktion zu brauchen? Damit man also das Programm per SA38 starten kann? Wow, was für ein Gewinn. Vor allem, weil Endanwender im Produktivsystem ihre Programme ja typischerweise alle per SA38 starten...
Also da finde ich die Anlage einer vernünftigen Starttransaktion (2 Minuten) und dann den ablaufkorrekten Einsprung ins erste Dynpro um Größenordnungen besser. Was Du geschildert hast, ist der Ansatz, aus Gewohnheit (!) alles mit Report zu machen und sich deshalb Krücken einfallen zu lassen, wie man auch Programme, die offenkundig keine Reports sind, technisch als solche deklarieren und zum Laufen bekommen kann. Bitter wird es, wenn dann hier im Forum behauptet wird, Modulpools seien veraltet (weil man sie nicht mehr gewohnt ist).
Über Formroutinen in externe Programme einzuspringen ist in aller Regel veraltet, doch gibt es historisch bedingte Fälle, in denen es dazu keine Alternative gibt. Die kürzlich in einem anderen Thread erwähnten Dynamischen Maßnahmen im HCM sind ein Beispiel. Dort kann man eigene Formroutinen schreiben und diese dann aus dem Standard aufrufen lassen, um den Standardablauf zu erweitern. Lass mich raten: Du würdest auch dafür einen "Report" anlegen, der nichts anderes enthält als jene Form-Routinen. Würde auch technisch funktionieren, wäre inhaltlich aber auch
, denn extra für solche Zwecke gibt es den Programmtyp "Subroutinenpool".
Und wozu? Um keine Transaktion zu brauchen? Damit man also das Programm per SA38 starten kann? Wow, was für ein Gewinn. Vor allem, weil Endanwender im Produktivsystem ihre Programme ja typischerweise alle per SA38 starten...
Also da finde ich die Anlage einer vernünftigen Starttransaktion (2 Minuten) und dann den ablaufkorrekten Einsprung ins erste Dynpro um Größenordnungen besser. Was Du geschildert hast, ist der Ansatz, aus Gewohnheit (!) alles mit Report zu machen und sich deshalb Krücken einfallen zu lassen, wie man auch Programme, die offenkundig keine Reports sind, technisch als solche deklarieren und zum Laufen bekommen kann. Bitter wird es, wenn dann hier im Forum behauptet wird, Modulpools seien veraltet (weil man sie nicht mehr gewohnt ist).
Über Formroutinen in externe Programme einzuspringen ist in aller Regel veraltet, doch gibt es historisch bedingte Fälle, in denen es dazu keine Alternative gibt. Die kürzlich in einem anderen Thread erwähnten Dynamischen Maßnahmen im HCM sind ein Beispiel. Dort kann man eigene Formroutinen schreiben und diese dann aus dem Standard aufrufen lassen, um den Standardablauf zu erweitern. Lass mich raten: Du würdest auch dafür einen "Report" anlegen, der nichts anderes enthält als jene Form-Routinen. Würde auch technisch funktionieren, wäre inhaltlich aber auch
, denn extra für solche Zwecke gibt es den Programmtyp "Subroutinenpool".
Beitrag
von black_adept (Top Expert / 4117 / 129 /
952
)
»
Das Ganze sind 2 Zeilen.DeathAndPain hat geschrieben:Was ist denn das für ein Krampf: Ein Report mit einem leeren Selektionsbild, dann kommt ein START-OF-SELECTION keiner Selektion und dann ein CALL SCREEN in das eigentliche Dynpro. Der ganze Code bis einschließlich des CALL SCREEN ist ein reiner Wasserkopf.
Code: Alles auswählen.
END-OF-SELECTION. CALL SCREEN 9000.Wozu? Beispiele:DeathAndPain hat geschrieben:Und wozu? Um keine Transaktion zu brauchen? Damit man also das Programm per SA38 starten kann? Wow, was für ein Gewinn. Vor allem, weil Endanwender im Produktivsystem ihre Programme ja typischerweise alle per SA38 starten...
- Definierter INITIALIZATION Zeitpunkt
- Wer sagt denn, dass das Ganze dann ohne Transaktionscode abgeht. Häufig wird bei mir am TxCode entschieden wie sich das Programm verhalten soll ( anzeigen, ändern, )
- Sonderaktionen die nicht für Anwender gedacht sind, die nicht bei Start über die Z-Transaktionscodes gehen
- Programm kann im Hintergrund eingeplant werden
Nicht aus Gewohnheit sondern ganz explizit so entschieden. Und die Technik der Modulpools ist ja nicht veraltet - ich verwende sie ja selber. Nur die Programmeigenschaft "Modulpool" halte ich für überholt. Bitter ist es, wenn Unwissen (durch Gewohnheit) unterstellt wird.DeathAndPain hat geschrieben:Was Du geschildert hast, ist der Ansatz, aus Gewohnheit (!) alles mit Report zu machen und sich deshalb Krücken einfallen zu lassen, wie man auch Programme, die offenkundig keine Reports sind, technisch als solche deklarieren und zum Laufen bekommen kann. Bitter wird es, wenn dann hier im Forum behauptet wird, Modulpools seien veraltet (weil man sie nicht mehr gewohnt ist).
Und finde mich damit in guter Gesellschaft, wenn man sich all die Druck"programme" von SAP im Vertrieb anschaut.DeathAndPain hat geschrieben:Über Formroutinen in externe Programme einzuspringen ist in aller Regel veraltet, doch gibt es historisch bedingte Fälle, in denen es dazu keine Alternative gibt. Die kürzlich in einem anderen Thread erwähnten Dynamischen Maßnahmen im HCM sind ein Beispiel. Dort kann man eigene Formroutinen schreiben und diese dann aus dem Standard aufrufen lassen, um den Standardablauf zu erweitern. Lass mich raten: Du würdest auch dafür einen "Report" anlegen, der nichts anderes enthält als jene Form-Routinen. Würde auch technisch funktionieren, wäre inhaltlich aber auch
P.S. Gut von Ralf gelernt, was deine Artikulation und Argumentation angeht!
Beitrag
von DeathAndPain (Top Expert / 1964 / 261 /
415
)
»
Das ist der einzige kleine Vorteil, den ich nachvollziehen kann, dass man sich die Definition eines Feldes INIT_DONE TYPE BOOLEAN_FLG spart, das dann im ersten PBO-Modul verarbeitet wird.Definierter INITIALIZATION Zeitpunkt
Super, dann haste erst recht keinen Vorteil mehr davon, keinen Modulpool verwendet zu haben.Wer sagt denn, dass das Ganze dann ohne Transaktionscode abgeht. Häufig wird bei mir am TxCode entschieden wie sich das Programm verhalten soll ( anzeigen, ändern, )
Sowas kommt bei mir nicht vor. Käme es vor, dann würde ich halt einen Transaktionscode mehr dafür machen. Aber ich prüfe da eher Berechtigungen und stelle dann im Programm ggf. erweiterte Optionen zur Verfügung.Sonderaktionen die nicht für Anwender gedacht sind, die nicht bei Start über die Z-Transaktionscodes gehen
Bei den Programmen, die sich für einen Modulpool eignen (also richtige Dialogverarbeitung mit Hin und Her und Daten einpflegen und Darstellung in Table Controls und Bla) macht eine Hintergrundeinplanung keinen Sinn. Sie würde auch nicht funktionieren, weil sie nämlich auf die Nase fällt, sobald Du Deinen CALL SCREEN machst.Programm kann im Hintergrund eingeplant werden
Es sei denn, Du meinst mit "Hintergrundverarbeitung" einfach Batch Input. Das funktioniert aber genauso auch mit Modulpools, solange man keine batch-input-untauglichen Elemente verwendet.
Habe ich eigentlich schon erwähnt, dass bei Deinem "Report" immer ein leeres, automatisch generiertes Müll-Dynpro 1000 anfällt?
Ja, die SAP macht selber leider auch eine Menge Pfusch, das stimmt.Und finde mich damit in guter Gesellschaft, wenn man sich all die Druck"programme" von SAP im Vertrieb anschaut.
Ne, ich war schon immer so drauf. Haste nur nicht gemerkt.P.S. Gut von Ralf gelernt, was deine Artikulation und Argumentation angeht!
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Nur wenn man einen der Befehle SELECTION-SCREEN, PARAMETERS oder SELECT-OPTIONS verwendet. Sonst wird da nichts generiert.DeathAndPain hat geschrieben:Habe ich eigentlich schon erwähnt, dass bei Deinem "Report" immer ein leeres, automatisch generiertes Müll-Dynpro 1000 anfällt?
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
Vergleichbare Themen
3
Antw.
Antw.
3511
Views
Views
9
Antw.
Antw.
1408
Views
Views
ABAP-Programm mit GUI-Status und Dynpro herunterladen
von L0w-RiDer » 25.11.2022 12:33 • Verfasst in ABAP® für Anfänger
von L0w-RiDer » 25.11.2022 12:33 • Verfasst in ABAP® für Anfänger
7
Antw.
Antw.
915
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.