Einfaches Dynpro mit Programm verbinden

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 ) » 7. Feb 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/radiobu ... ge-felder/

Die Möglichkeit bestimmte Felder einfach auszublenden und somit Wahlmöglichkeiten oder Eingabemöglichkeiten einzuschränken ist perfekt.


Re: Einfaches Dynpro mit Programm verbinden

Beitrag von DeathAndPain (Top Expert / 1012 / 115 / 223 ) » 7. Feb 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).

Re: Einfaches Dynpro mit Programm verbinden

Beitrag von ewx (Top Expert / 3917 / 160 / 348 ) » 7. Feb 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".

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


Re: Einfaches Dynpro mit Programm verbinden

Beitrag von DeathAndPain (Top Expert / 1012 / 115 / 223 ) » 7. Feb 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".

Re: Einfaches Dynpro mit Programm verbinden

Beitrag von black_adept (Top Expert / 3217 / 54 / 559 ) » 7. Feb 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

Re: Einfaches Dynpro mit Programm verbinden

Beitrag von DeathAndPain (Top Expert / 1012 / 115 / 223 ) » 7. Feb 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

Re: Einfaches Dynpro mit Programm verbinden

Beitrag von a-dead-trousers (Top Expert / 3199 / 81 / 792 ) » 7. Feb 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

Vorherige Seite 2 von 2 (current)

Aktuelle Forenbeiträge

Business Partner Konzept
vor 2 Stunden von msfox 3 / 217
Exception Handling FuBa test
vor 9 Stunden von ichse18577 1 / 40
CDS-Views / AMDP für HCM
vor 12 Stunden von RaCDigger 6 / 316
Kreditlimitprüfung Obligo
vor 17 Stunden von SAP_ENTWICKLER 3 / 163

Unbeantwortete Forenbeiträge

Exception Handling FuBa test
vor 9 Stunden von ichse18577 1 / 40
Verursachervormerkung OCM manuell anlegen
vor 6 Tagen von Aba 1 / 127
Auflösen MILL_OC - Auftragszusammenfassung
vor einer Woche von tofralu 1 / 109
Löschen von archivierten Drucklisten
vor einer Woche von Asaph 1 / 99