Best Practices Formularentwicklung - Coding

Aus SAP-Wiki
Wechseln zu: Navigation, Suche

Break-Points

Bei der Formularentwicklung gibt es sehr häufig den Fall, dass man im Entwicklungssystem in einem Mandanten entwickelt und im anderen Mandanten testet. Das hat den Nachteil, dass man im Entwicklungsmandanten keinen Session-Breakpoint oder externen Breakpoint setzen kann. Man kann im Testmandanten die Codingstelle aufrufen und dort den Session-Breakpoint setzen. Das nervt jedoch, da man so immer zwischen zwischen den zwei Mandanten und Codingstellen hin und her springen muss.

Einfacher ist es im Code einen Breakpoint zu setzen.

Break-Point

Der Breakpoint sollte jedoch nie gesetzt werden mit dem Befehl

break-point.

Es wird leicht bei einem Transport vergessen den Breakpoint zu entfernen und es ist peinlich, wenn z. B. ein Keyuser beim Test in den Debugger springt. Da wird dann auch für den Keyuser offensichtlich, dass man schlampig gearbeitet hat. Das sollte vermieden werden.

break <username>

Wesentlich besser ist es den Breakpoint mittels der Transaktion SAAB zu setzen oder mit dem Codingbefehl

break username.

Hier wird es vielleicht auch mal vergessen den Breakpoint zu entfernen beim Transport, aber es merkt keiner, da der Breakpoint nur beim eigenen SAP-User angesprungen wird.

break <username> "Beschreibung

Empfehlenswert ist es auch einen auskommentierten Breakpoint vor dem Aufruf des Formulars zu setzen und einen Kommentar hinter den Breakpoint zu setzen, damit man leicht den richtigen Breakpoint erkennen kann. An dieser Stelle sind alle Variablen im Rahmenprogramm gefüllt. Das wird eine Codingstelle sein, die man regelmäßig debuggen wird, um zu prüfen ob eine Variable im Rahmenprogramm gefüllt wurde. Bei der Suche nach dem String "break" wird er als Fundstelle ausgewiesen

FormularBestPractices1.jpg

und kann sofort angesprungen werden und bei der gesamten Zeile die Kommentierung entfernt bzw. gesetzt werden.

 "break username. "vor dem Formularaufruf

  CALL FUNCTION lv_func_name
    EXPORTING
     ...

break/Suche nach 'CALL FUNCTION L'

Eine sehr schnelle clevere Methode um direkt zum Aufruf des Funktionsbausteins (Smart Forms/Adobe Forms) zu kommen, ist nach dem String "CALL FUNCTION L" zu suchen. Normalerweise werden die wenigsten Funktionsbausteine mit dem Buchstaben L beginnen. Bei Smart Forms und bei Adobe Forms wird der Funktionsbaustein zum Aufruf des Formulars in jedem System generiert. Es sind pro System also unterschiedliche Programmnamen. Der Name des Funktionsbausteins wird daher in einer lokalen Variable während der Laufzeit gefunden. Er heißt meist "LV_FUNC_NAME" oder ähnlich.

  CALL FUNCTION lv_func_name
    EXPORTING
     ..

Mit dem Suchstring "CALL FUNCTION L" (unabhängig ob Groß-/Kleinschreibung) lässt sich dieser Aufruf sehr schnell finden und anspringen.

CallFunctionL1.jpg


Fundstelle wird angezeigt.

CallFunctionL2.jpg


Sprung zum Coding durch Doppelklick auf die Fundstelle.

CallFunctionL3.jpg

Kopiervorlagen

  • Für ein zu erstellendes Formular gibt es mindestens zwei Entwicklungsobjekte, die anzulegen sind. Einmal das Druckrahmenprogramm und das Formular. Hier sollte man ein paar Minuten investieren und ein altes Druckrahmenprogramm und Formular identifizieren, die möglichst ähnlich zum zu erstellenden Druckrahmenprogramm und Formular sind und die kopieren. Im Zweifel lieber Vorlagen verwenden, die umfangreicher sind als die zu erstellenden Objekte. Löschen ist leicht und schnell gemacht, Nachprogrammieren deutlich aufwendiger.

Druckprogramm mit Default-Selektionsvariante

  • Während der Formularentwicklung wird man ein Druckprogramm viele male ausführen, um die Ergebnisse des Formulars auf dem Bildschirm oder auf dem Ausdruck zu kontrollieren. Normalerweise wird man dabei immer mit dem gleichen Beleg arbeiten. Um sich die Zeit zu sparen diesen Beleg manuell immer wieder neu einzutragen, sollte man im Selektionsparameter (bei ausführbaren Reports) den Beispielbeleg als Defaultwert eintragen
PARAMETERS: p_lfrgn  type likp-vbeln DEFAULT '0080291443'.
  • Vor dem Transport ins Q-System sollte diese Variante natürlich gelöscht werden. Aber auch wenn man dies vergisst, fällt es schnell auf und ist in wenigen Minuten korrigiert.
  • Auch wenn man bei der Formularausgabe über die Belegtransaktion geht, z. B. VL03N (Auslieferung anzeigen), dann lässt sich der Testbeleg mit der SPACE-Taste schnell auswählen. Steht diese nicht zur Verfügung, dann liegt dies an einem Bug und kann durch einen einmaligen Eingriff in die Registry gefixt werden.

Erweiterte Syntaxprüfung

  • Bevor man ein Druckrahmenprogramm zum Transport ins Q -oder P-System freigibt, ist es dringend zu empfehlen die erweiterte Sytaxprüfung durchzuführen. Hier wird man z. B. auf vergessene Breakpoints hingewiesen.
  • Transaktion SLIN (erweiterte Syntaxprüfung)

Sammlung Entwicklungsobjekte in ein Paket

  • Sehr empfehlenswert ist es alle Entwicklungen zu einem Formularentwicklungsprojekt in ein Paket zu speichern. So hat man mit SE80 alle Entwicklungsobjekte sehr übersichtlich auf einen Blick.

Hilfsprogramm zum Durchsuchen von Coding

  • Sehr häufig wird man Codingstellen wieder aufrufen. Mit dem SAP-Programm RS_ABAP_SOURCE_SCAN lässt sich sehr komfortabel Coding innerhalb diverser Programme oder Pakete anzeigen und aufrufen. Speziell in einem zeitlich fortgeschrittenen Projekt ist das Programm sehr wertvoll, da es hier viele existierende Programme bzw. Paket(e) gibt und man so sehr schnell existierendes Coding findet, was man an anderer Stelle wiederverwenden kann.
  • Wenn das Programm häufig genutzt wird sollte ein Modus für dieses Programm reserviert werden.
  • Bestimmte Selektionen z. B. nach einem (Entwicklungs-)Paket sollte man als Variante abspeichern, um so möglichst schnell die Selektionskriterien zu füllen, v. a. wenn die Selektionen komplexer sind.