Einfaches Dynpro mit Programm verbinden

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
22 Beiträge • Vorherige Seite 2 von 2 (current)
22 Beiträge Vorherige Seite 2 von 2 (current)

Re: Einfaches Dynpro mit Programm verbinden

Beitrag von Abapsocke (ForumUser / 49 / 6 / 0 ) »
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.

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Einfaches Dynpro mit Programm verbinden

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
black_adept hat geschrieben:Nenn mal ein einziges Beispiel, wo ein Modulpool flexibler ist als ein Report
Gleich mehrere:
  • 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)
Soweit Obenstehendes mit einem Report möglich ist, dann nur mit großem Gekrampfe und Zauberei im Bereich des AT SELECTION-SCREEN, wodurch eine Programmstruktur entsteht, die vom Ablauf her mit einem Report nichts zu tun hat, schlecht nachvollziehbar ist, und krampfig programmiert ist. Gewissermaßen ein aufwendiger Workaround dafür, dass man nicht den einfachen Weg des Modulpools mit selbstgestaltetem Einstiegsdypro gegangen ist.

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

Re: Einfaches Dynpro mit Programm verbinden

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
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".

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag (Insgesamt 2):
a-dead-trousersblack_adept


Re: Einfaches Dynpro mit Programm verbinden

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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 :x , denn extra für solche Zwecke gibt es den Programmtyp "Subroutinenpool".

Re: Einfaches Dynpro mit Programm verbinden

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.
Das Ganze sind 2 Zeilen.

Code: Alles auswählen.

 END-OF-SELECTION.  CALL SCREEN 9000.
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...
Wozu? Beispiele:
  • 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
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).
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:Ü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 :x , denn extra für solche Zwecke gibt es den Programmtyp "Subroutinenpool".
Und finde mich damit in guter Gesellschaft, wenn man sich all die Druck"programme" von SAP im Vertrieb anschaut.


P.S. Gut von Ralf gelernt, was deine Artikulation und Argumentation angeht!
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Einfaches Dynpro mit Programm verbinden

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Definierter INITIALIZATION Zeitpunkt
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.
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, )
Super, dann haste erst recht keinen Vorteil mehr davon, keinen Modulpool verwendet zu haben.
Sonderaktionen die nicht für Anwender gedacht sind, die nicht bei Start über die Z-Transaktionscodes gehen
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.
Programm kann im Hintergrund eingeplant werden
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.

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?
Und finde mich damit in guter Gesellschaft, wenn man sich all die Druck"programme" von SAP im Vertrieb anschaut.
Ja, die SAP macht selber leider auch eine Menge Pfusch, das stimmt.
P.S. Gut von Ralf gelernt, was deine Artikulation und Argumentation angeht!
Ne, ich war schon immer so drauf. Haste nur nicht gemerkt. :P

Re: Einfaches Dynpro mit Programm verbinden

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
DeathAndPain hat geschrieben:Habe ich eigentlich schon erwähnt, dass bei Deinem "Report" immer ein leeres, automatisch generiertes Müll-Dynpro 1000 anfällt?
Nur wenn man einen der Befehle SELECTION-SCREEN, PARAMETERS oder SELECT-OPTIONS verwendet. Sonst wird da nichts generiert.
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

Vergleichbare Themen

3
Antw.
3222
Views
Einfaches Ausgabefeld auf Dynpro
von hausi » 20.11.2015 11:42 • Verfasst in ABAP® für Anfänger
9
Antw.
380
Views
ABAP-Programm mit GUI-Status und Dynpro herunterladen
von L0w-RiDer » 25.11.2022 12:33 • Verfasst in ABAP® für Anfänger
1
Antw.
974
Views
Einfaches AV Grid
von Paul » 26.10.2018 14:37 • Verfasst in ABAP® für Anfänger
5
Antw.
3433
Views
Idoc - einfaches Beispiel
von Gast » 14.03.2005 20:20 • Verfasst in Basis
32
Antw.
26694
Views
Einlesen elektr. Kontoauszug - Einfaches Beispiel
von Blueshape » 27.07.2004 09:06 • Verfasst in Financials

Ü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

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140