gelöst Einfaches Dynpro mit Programm verbinden


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

Re: Einfaches Dynpro mit Programm verbinden

Beitragvon Abapsocke » 07.02.2019, 09:00

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/radiobuttons-und-zugehoerige-felder/

Die Möglichkeit bestimmte Felder einfach auszublenden und somit Wahlmöglichkeiten oder Eingabemöglichkeiten einzuschränken ist perfekt.
Abapsocke
ForumUser
 
Beiträge: 43
Registriert: 17.04.2018, 15:34
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Einfaches Dynpro mit Programm verbinden

Beitragvon DeathAndPain » 07.02.2019, 12:51

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).
DeathAndPain
Expert
 
Beiträge: 934
Registriert: 05.05.2006, 10:14
Dank erhalten: 218 mal
Ich bin: Entwickler/in

Re: Einfaches Dynpro mit Programm verbinden

Beitragvon ewx » 07.02.2019, 13:26

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

Für diese Nachricht hat ewx 2 Dankeschön bekommen :
a-dead-trousers, black_adept
ewx
Top Expert
 
Beiträge: 3868
Registriert: 04.08.2003, 19:55
Wohnort: Schleswig-Holstein
Dank erhalten: 334 mal

Re: Einfaches Dynpro mit Programm verbinden

Beitragvon DeathAndPain » 07.02.2019, 13:52

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".
DeathAndPain
Expert
 
Beiträge: 934
Registriert: 05.05.2006, 10:14
Dank erhalten: 218 mal
Ich bin: Entwickler/in

Re: Einfaches Dynpro mit Programm verbinden

Beitragvon black_adept » 07.02.2019, 14:45

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
black_adept
Top Expert
 
Beiträge: 3184
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 553 mal
Ich bin: Freiberufler/in

Re: Einfaches Dynpro mit Programm verbinden

Beitragvon DeathAndPain » 07.02.2019, 16:49

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
DeathAndPain
Expert
 
Beiträge: 934
Registriert: 05.05.2006, 10:14
Dank erhalten: 218 mal
Ich bin: Entwickler/in

Re: Einfaches Dynpro mit Programm verbinden

Beitragvon a-dead-trousers » 07.02.2019, 19:32

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.07
Basis: 7.40
a-dead-trousers
Top Expert
 
Beiträge: 3152
Registriert: 07.02.2011, 13:40
Dank erhalten: 778 mal
Ich bin: Entwickler/in

Vorherige

Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
gelöst SALV - Layout wird nicht gezogen
vor 7 Stunden von ralf.wenzel 0 Antw.
ADRMAS-Segmente vorbefüllen
vor 10 Stunden von lausek 0 Antw.
MS Word nicht als SAPscript-Editor verwenden
vor 11 Stunden von DeathAndPain 2 Antw.
EWM: HU mit RBG anhand von Produkt-LB bewegen
Gestern von TimTo 0 Antw.
BADI Impl. cin_plug_in_to_migo deaktivieren
Gestern von zzcpak 1 Antw.

  Ähnliche Beiträge beta
gelöst Einfaches Ausgabefeld auf Dynpro
20.11.2015, 12:33 von hausi 3 Antw.
Einfaches AV Grid
26.10.2018, 13:41 von Legxis 1 Antw.
Einfaches Löschprogramm für Tabelleninhalte
09.02.2004, 17:06 von X-Sight 7 Antw.
Variablenname + Laufende Nummer verbinden
16.04.2010, 08:21 von metbo 3 Antw.
gelöst wie kan man zwei interen tabellen verbinden?
15.07.2014, 07:59 von autohandel7 13 Antw.

 

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot]