gelöst Einfaches Dynpro mit Programm verbinden

[Abapsocke]

Ich brauche ein Beispiel dafür, wie ich ein einfaches Dynpro mit dem Screenpainter erstelle und dessen Daten in ein Programm überführe.
Wie ich Felder mit dem Screen Painter erstelle oder Radiobuttons gruppiere weiß ich, aber nicht wie ich die Daten vom Dynpro weiterleite und ob es richtig ist, den Dynproaufruf an den Anfang des Programms zu stellen.


Ausgangslage ist Folgende:

Ich benötige von dem User eine Auswahl mit Radiobutton, bei der er sich entscheidet ob er Daten importieren oder exportieren möchte. Außerdem muss er bei einem Import eine Zahl angeben. Diese Angaben sollen in das Programm übertragen werden, also den Report in dem die hauptsächliche Funktionalität abläuft.

Zuerst habe ich das mit Funktionsbausteinen, wie POPUP Get Value versucht, aber ich habe keine Ahnung wie ich damit einen Zahlenwert abfragen kann, ohne das er im Infotext Benutzername stehen hat. Denke das wäre alles mit Dynpro einfacher.
Trotzdem hier als Beispiel der Code für den FUBA:

Code: Alles auswählen

 ls_query-tabname            = 'USR01'. "Das führt anscheinend zur Anzeige "Benutzername", weiß aber nicht was ich da sonst hinschreiben muss
      ls_query-fieldname         = 'BNAME'.
      append ls_query to lt_query.


START-OF-SELECTION.

CALL FUNCTION 'POPUP_GET_VALUES'
  EXPORTING
    popup_title         ='Please input the exact number of your DATA.'
  TABLES
    fields              = lt_query
  EXCEPTIONS
    error_in_fields = 1
    others          = 2.

  READ TABLE lt_query INTO ls_query with key fieldname = 'BNAME'.
  IF sy-subrc = 0.
    write:/ ls_query-value.


  ENDIF.

[ewx]

Daten werden zwischen Programm und Dynpro durch Namensgleichheit übertragen.
Das heißt, du kannst eine globale Variable oder eine Tabelle/ Struktur, die du mittels TABLES-Anweisung bekannt gegeben hast, im Dynpro anzeigen.
Die Werte werden aus den Eingabefeldern im PAI (Process After Input) übernommen.
Siehe Programme DEMO_DYNPRO*

[DeathAndPain]

Da es hier offenbar um die Grundlagen geht, würde ich hinzufügen wollen, dass Du für solch Programm nicht den Programmtyp "Ausführbares Programm" (also keinen REPORT) verwenden solltest. Ich sage das, weil viele Entwickler reflexartig für alles den REPORT-Typ verwenden, selbst für Subroutinenpools (und leider lässt ABAP ihnen das durchgehen). Es gibt zwar Möglichkeiten, auch in Reports eigene Dynpros einzuhängen, aber das ist fortgeschrittene Programmierung und sollte nicht verwendet werden, bevor man nicht mit "normalen", Dynpro-basierten Programmen Erfahrung gesammelt hat.

Was Du stattdessen machen musst, ist folgendes:

• Lege in der SE38 ein Programm vom Typ "Modulpool" an.
• Lege in der SE51 für das soeben angelegte Programm ein oder mehrere Dynpros an.
• Lege in der SE93 einen Transaktionscode vom Typ "Dialogtransaktion" an, der auf das Dynpro verweist, mit dem Du starten möchtest.
• Lege wieder in der SE38 globale Felder an, die den Namen der Felder tragen, die Du in Deinem Dynpro verwendest. Wie ewx schon sagte, bewirkt dies, dass die Werte dieser Felder automatisch in das und aus dem Dynpro transportiert werden.
• Lege in der SE43 einen GUI-Status an, in dem Du die möglichen Okcodes definierst. Minimal solltest Du die Abbruch-Schaltflächen (den grünen Pfeil, das rote Kreuz usw.) hier definieren, damit Du einen Okcode bekommst, mit dem Du Dein Programm zumindest mal wieder verlassen kannst. Füge Deinem PBO-Modul einen entsprechenden Befehl SET PF-STATUS hinzu.
• Lege in Deinem Dynpro ein PBO-Modul an, in dem Du notwendige Initialisierungen (Feldvorbelegungen usw.) triffst.
• Lege in Deinem Dynpro ein PAI-Modul an, in dem Du den SY-UCOMM verarbeitest. Du kannst auch eine globale Variable als OKCODE anlegen und ihren Namen in den Feldeigenschaften des Dynpros als OKCODE-Variable hinterlegen.

Statt der ganzen o.g. Transaktionen kannst Du natürlich auch alles mit der SE80 machen. Aber die SE80 ist ein behäbiger Brocken, der mir nicht gefällt. Jedem das Seine.

[black_adept]

Hallo Abapsocke,

was du beschreibst ist ein "Vorschaltprogramm". All das was ewx und D&P geschrieben haben solltest du ruhig berücksichtigen wenn du mal vorhast einen Modulpool zu schreiben. Aber für das was du beschreibst ist das völlig oversized.
Bau dir einen ganz normalen Report der de facto nur aus einem Selektionsbild besteht ( Siehe Doku zu PARAMETERS, PARAMETERS ... CHECKBOX oder PARAMETERS ... RADIOBUTTON GROUP ). Dann kannst du dir den gesamten Feldtransport schenken, weil SAP dir die Daten einfach in den Parameterfeldern zurück gibt und du dann einfach im Programmcoding ein "SUBMIT" auf das eigentliche Programm machen kannst

@D&P "Fortgeschrittene Programmierung bei Einhängen von Dynpros in Reports"? Ich schreibe andauernd neue Progrämmchen, welche diverse Dynpros verwenden. Aber wann ich dafür tatsächlich noch einen Modulpool verwendet habe - ich kann mich nicht erinnern das in den letzten 10 Jahren noch gemacht zu haben. Gibt es noch einen Grund einen Modulpool zu verwenden - diese Trennung von Modulpool und Report kommt m.W. noch aus R/2 Zeiten und ist seit R/3 eigentlich überflüssig. Und ich kann dir diverse Vorteile von Reports gegenüber Modulpools erzählen - aber umgekehrt fällt mir auf die Schnelle keiner mehr ein.

[Abapsocke]

Mit Parameters komme ich nicht weiter, da ich diese ja immer an den Anfang stellen muss als Data, aber die Abfrage erst später kommen soll.
Ich sehe da nicht mehr klar, habe es jetzt nochmal mit Dynpro versucht, komme aber nicht weiter.

zum Code gibt es ein Dynpro mit zwei Radiobuttons. Ich möchte ganz unten einfach einen Text ausgeben, aber nach dem endmodule liest der Parser nicht mehr weiter.. Warum? Er soll das Dynpro starten, die Werte ablesen, damit ich dann damit im Programm arbeiten kann.

Ob Report oder MOdulepool oder wasauchimmer ist gerade nicht relevant. Es geht mir nur darum einmal ein Beispiel für diese einfache Kombination zu haben, um zu wissen wo das Problem liegt.

Ich will gerade nur am Ende eine Textausgabe haben, wenn der t1 Radiobutton geklickt wurde. Im Debugger sehe ich auch, dass die Werte korrekt weitergegeben werden, aber es gibt eben keine Ausgabe. Die brauche ich aber.

Code: Alles auswählen

REPORT  ZLK_DYNPROTEST.


DATA: input TYPE i,

output TYPE i,

lv_test(4) TYPE c,

t1(1) TYPE c, t2(1) TYPE c.

CALL SCREEN 6666.

MODULE init_screen_6666 output.

CLEAR input.

t1 = 'X'.

CLEAR: t2.

ENDMODULE.

MODULE user_command_6666 input.

output = input.




*IF exit NE space.
*
*LEAVE PROGRAM.

*ENDIF.

IF t1 = 'X'.
  lv_test ='test'.

  write:lv_test.
ENDIF.

ENDMODULE.

[deejey]

Das sieht alles nach Kraut und Rüben aus, du kommst nicht weiter weil du das Konzept dahinter nicht verstehst. Es gibt doch diese Beispiel-Dynproprogramme, wie zum Geier heißen die nochmal? Das ist mMn der beste Einstieg.

[ewx]

Du kannst in einem dynpro keine Ausgabe mit WRITE erzeugen!
Probier Mal statt dessen MESSAGE 'text' Type 'i'. Um zu sehen dass die dynpro Eingabe funktioniert.

[Abapsocke]

hab es jetzt verstanden. Mein Problem lag im Grundlegenden Ablauf wie der Parser beim Lesen des Codes mit einem Dynpro vorgeht, also das er in dem Call Screen Moment abspringt und ich daher nach CALL SCREEN den Befehl einfügen müsste. Jetzt kann ich auch die anderen Informationen verwenden, um tiefer in die Thematik einzusteigen.

[Abapsocke]

Das sieht alles nach Kraut und Rüben aus, du kommst nicht weiter weil du das Konzept dahinter nicht verstehst. Es gibt doch diese Beispiel-Dynproprogramme, wie zum Geier heißen die nochmal? Das ist mMn der beste Einstieg.

kann nicht wirklich nach kraut und rüben aussehen weil es fast 1 zu 1 das Beispiel aus der sap dokumentation ist
hab nur die namen der variablen geändert.

https://help.sap.com/doc/saphelp_nw73/7.3.16/de-DE/4a/44a8dd76f0044ee10000000a421937/frameset.htm

so wie unten läufts dann auch.

Code: Alles auswählen

DATA: input TYPE i,

output TYPE i,

lv_test(4) TYPE c,

t1(1) TYPE c, t2(1) TYPE c.

CALL SCREEN 6666.

IF t1 = 'X'.
  lv_test ='test'.

  write:lv_test.
ENDIF.

MODULE init_screen_6666 output.

CLEAR input.

t1 = 'X'.

CLEAR: t2.

ENDMODULE.

MODULE user_command_6666 input.

output = input.




*IF exit NE space.
*
*LEAVE PROGRAM.

*ENDIF.

LEAVE SCREEN.



ENDMODULE.

[DeathAndPain]

Es sieht eben doch wie Kraut und Rüben aus, und zwar deshalb, weil Du mitten im PAI eines Dynpros einen WRITE-Befehl geschrieben hast, der da nicht hingehört.

Wobei, so ganz richtig ist das auch nicht. Du kannst sehr wohl im PAI eines eigenen Dynpros WRITE verwenden. Du musst vorher nur den Befehl LEAVE TO LIST-PROCESSING AND RETURN TO SCREEN '0'. bringen. Lies Dir die Online-Doku dazu ruhig mal durch; vielleicht kannst Du das mal brauchen.

was du beschreibst ist ein "Vorschaltprogramm".

Und ein "Vorschaltprogramm" ist was? Letztlich entnehme ich Deinen Worten, dass Du das Selektionsbild des Reports selbst als "Vorschaltprogramm" verstehst, was man sicherlich vertreten kann. Nur hat er ja deutlich gemacht, dass ihm genau das eben nicht reicht und dass er da eine erweiterte, flexible Programmsteuerung haben möchte. Und in dem Moment, in dem das so ist, ist ein Report mit seiner einfachen Selektionsbild -> Ergebnisliste-Struktur nicht mehr ausreichend, sondern dann braucht man eine flexible Programmablaufsteuerung. Die einzige Alternative wäre, über FUNCTION KEY Schaltflächen in das Selektionsbild einzubauen und bei deren Nutzung dann aus dem entsprechenden AT SELECTION-SCREEN-Block einen CALL SCREEN auszuführen.

Ich schreibe andauernd neue Progrämmchen, welche diverse Dynpros verwenden. Aber wann ich dafür tatsächlich noch einen Modulpool verwendet habe - ich kann mich nicht erinnern das in den letzten 10 Jahren noch gemacht zu haben.

Würde gerne mal wissen, wie das aussehen soll. Ein Report generiert Dir aus Deinem Selektionsbild ein Dynpro 1000. Bei Abfahrt geht es in das Ergebnisbild. Viel mehr kann ein Report nicht. Vielleicht kannst Du den Ablauf umbiegen, indem Du im Ereignis START-OF-SELECTION dann plötzlich andere Dynpros per CALL SCREEN rufst, aber das kommt mir wie eine üble Vergewaltigung des REPORT-Konzeptes vor. Ich sehe auch keine Vorteile; im Gegenteil bist Du bei der Gestaltung Deines Selektionsbildes auf die Möglichkeiten beschränkt, die die Report-Programmierung Dir bietet, anstatt Dein Einstiegsdynpro komfortabel per WYSIWYG zu erstellen und dabei alle Möglichkeiten offen zu haben. Allein das Gekrampfe, dass PARAMETERS-Feldnamen nur maximal 8 Zeichen lang sein dürfen, was aussagekräftige Feldnamen zunichte macht, oder dass die Selektionstexte auch auf eine oft unzureichend kurze Länge beschränkt sind, die man sich aufwendig durch die kalte Küche erweitern muss, indem man einen SELECTION-SCREEN BEGIN/END OF LINE-Block baut und dann ein Textsymbol anstelle des normalen Selektionstextes für den Parameter verwendet...

Wenn man einige Parameter erfragen und dann eine wie auch immer geartete Liste ausgeben (oder aufgrund der eingegebenen Daten sonst irgendwas veranstalten) will, dann ist ein Report optimal. Tatsächlich sind das die meisten Anwendungsfälle, so dass auch ich nur noch sehr selten einen Modulpool baue. Aber in dem Moment, in dem Du z.B. eine Pflegetransaktion für etwas baust, ist ein Report Mist. Versuch mal, eine MM01/MM02 als Report zu bauen! Ganz zu schweigen von einer SE80. Das wird auf jeden Fall eine Vergewaltigung des Reportkonzeptes. Erst recht wenn das Programm komplexer ist und man in Unter-Dynpros verzweigen muss.

[ewx]

Ich schreibe andauernd neue Progrämmchen, welche diverse Dynpros verwenden. Aber wann ich dafür tatsächlich noch einen Modulpool verwendet habe - ich kann mich nicht erinnern das in den letzten 10 Jahren noch gemacht zu haben.

Würde gerne mal wissen, wie das aussehen soll. Ein Report generiert Dir aus Deinem Selektionsbild ein Dynpro 1000. Bei Abfahrt geht es in das Ergebnisbild. Viel mehr kann ein Report nicht. Vielleicht kannst Du den Ablauf umbiegen, indem Du im Ereignis START-OF-SELECTION dann plötzlich andere Dynpros per CALL SCREEN rufst, aber das kommt mir wie eine üble Vergewaltigung des REPORT-Konzeptes vor.

Das ist eine ganz normale Vorgehensweise. Du kommentierst das, als wäre das Zauberei...
Der Vorteil eines Selektionsbildes ist genau das: du kannst mit einem Befehl eine komplexe Selektion definieren (SELECT-OPTIONS). Eine Liste ist eben nicht mehr nur eine Liste, sondern ein ALV oder ein Tree oder eine Kombination. Und dafür macht man einen Call screen, der dann die Controls enthält. und wenn man dann für einen Doppelklick oder sonstwas einen anderen Screen braucht, dann wird der im Report entsprechend aufgerufen.

[DeathAndPain]

Das ist eine ganz normale Vorgehensweise. Du kommentierst das, als wäre das Zauberei...

Ich halte es nicht für Zauberei, sondern für eine Vergewaltigung des REPORT-Prinzips. CALL SCREEN kannste gerne im Ergebnisbild machen, wenn Du im I_CALLBACK_USER_COMMAND-Programm, das Du bei Deinem CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY' angegeben hast, mit Reaktionen des Users auf die Ergebnisliste umgehst. Das mache ich auch gerne. Aber da hast Du immer noch das Grundgerüst Selektionsbild->Ergebnisliste->weiteres. In dem Moment, in dem Du keine "Ergebnisliste" brauchst, weil Dein Programm etwas anderes tut, als nach Entgegennahme von Selektionsdaten Ergebnisdaten auszugeben, passt der Report als Programmtyp nicht mehr. Reports haben da eine beachtliche Flexibilität. Z.B. kannst Du einen Korrekturreport Daten verändern lassen, und die "Ergebnisliste" ist dann halt das Log. Aber sobald es darum geht, Daten einzupflegen statt rauszuholen, passt dieses Gerüst in aller Regel nicht mehr.

Der Vorteil eines Selektionsbildes ist genau das: du kannst mit einem Befehl eine komplexe Selektion definieren (SELECT-OPTIONS).

Wenn ich das in einem Modulpool brauche, dann mache ich einfach einen CALL SELECTION-SCREEN. Da habe ich alle Möglichkeiten des Report-Selektionsbildes, ohne die Flexibilität des Modulspools herschenken zu müssen. Brauche ich aber nur extrem selten, denn wenn ich es bräuchte, dann wäre es höchstwahrscheinlich von der Struktur her ein Report, und dann würde ich auch einen draus machen.

[black_adept]

Da habe ich alle Möglichkeiten des Report-Selektionsbildes, ohne die Flexibilität des Modulspools herschenken zu müssen

Nenn mal ein einziges Beispiel, wo ein Modulpool flexibler ist als ein Report

[black_adept]

was du beschreibst ist ein "Vorschaltprogramm".

Und ein "Vorschaltprogramm" ist was? Letztlich entnehme ich Deinen Worten, dass Du das Selektionsbild des Reports selbst als "Vorschaltprogramm" verstehst, was man sicherlich vertreten kann. Nur hat er ja deutlich gemacht, dass ihm genau das eben nicht reicht und dass er da eine erweiterte, flexible Programmsteuerung haben möchte.

Aus dem 1. Posting war nicht klar, dass es das selbe Programm ist aus dem die Zusatzinformationen abgefragt werden. --> Vorschaltprogramm um die Usereingaben zu holen und dann dem "richtigen" Programm zu übergeben. Aber ok - der TE will was anderes.
Die Aussage meines 1. Postings hingegen bleibt. Ein einfacher "CALL SELECTION SCREEN" um die Daten abzufragen ist viel einfacher als ein Dynpro dafür zu erstellen. Sieht nachher fast gleich aus - man verliert ein wenig Gestaltungsmöglichkeit und gewinnt viel Übersichtlichkeit im Programm.

Und in dem Moment, in dem das so ist, ist ein Report mit seiner einfachen Selektionsbild -> Ergebnisliste-Struktur nicht mehr ausreichend, sondern dann braucht man eine flexible Programmablaufsteuerung.

Diese doch sehr vereinfachte Ansicht war vielleicht zur Jahrtausendwende mal aktuell. Heutzutage ist ein Report beileibe nicht mehr SelScreen -> Ergebnisliste. Hat Enno ja auch schon erwähnt.
Ansonsten gilt: Man kann aus Modulpool in die Listverarbeitung wechseln und aus einem Report in die Dynprologik. Die Trennung ist somit ein Relikt aus dem Ursumpf des ABAP. Und wie gesagt - ich kenne keinen Vorteil den Programmtyp "Modulpool" zu verwenden. Es gibt nur diverse Mysteriösitäten mit einigen Zeitpunkten, wenn man in einem "echten" Modulpool via CALL SELECTION-SCREEN in die Report-Variante wechselt - umgekehrt hingegen nicht. Und ich möchte wetten, dass du mir nichts nennen kannst, das nur mit einem "echten" Modulpool geht was nicht nahezu genau so einfach mittels Report gemacht werden könnte.

[Abapsocke]

Nichts für ungut, aber das kommt ziemlich weit vom Thema ab. Mir persönlich hätte es sehr geholfen wenn der Tipp gekommen wäre, dass ein Dynproaufruf, also das Call Screen im Prinzip ein Absprungpunkt ist, der Parser also nicht von oben nach unten liest, sondern in dem Moment in die Programmlogik des Dynpros springt, dort BPO und dann PAI durchführt und dann wieder in die Lücke nach Call Screen springt. Die weiterführenden Infos sind nett und etwas mit dem ich mich bei Gelegenheit eingehender beschäftigen werde, halfen mir aber nicht direkt.

Ich stehe allerdings bei einer Frage die sich mir bei den Antworten nicht so ganz erschließt:

Wie gehe ich vor:
Ich weiß nun wie ich das, was ich haben möchte mit einem Dynpro hinbekomme, aber das scheint mir nach den Aussagen mancher wohl etwas überfrachtet zu sein, also wie besser?
Ich brauche einen Userinput am Anfang, also die Wahl ob der User etwas Importieren oder Exportieren will und sollte er Importieren wollen, muss der User danach aufgefordert werden ein Value einzugeben.
Wenn ich das habe, wäre mein Problem gelöst.

Es hieß, man könne das alles auch mit Params machen, nur wie?
Ich kenne die Parametereingabe so, dass ich die Variable direkt am Anfang deklarieren muss und habe alternativ die Möglichkeit gefunden mit Get Value und Co Daten vom Nutzer abzufragen, also in Form von Funktionsbausteinen.
Ich werde gezielt noch einmal nach den verschiedenen Möglichkeiten des Userinputs suchen, wenn aber jemand ein schnelles Beispiel dafür parat hat, wäre das sehr hilfreich.