Ansicht
Dokumentation

ABENGLOBAL_DECLAR_GUIDL - GLOBAL DECLAR GUIDL

Fill RESBD Structure from EBP Component Structure   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Globale Deklarationen eines Programms

Jedes ABAP-Programm hat einen globalen Deklarationsteil, in dem Datentypen, Interfaces, Klassen und Datenobjekte deklariert werden können, die im gesamten Programm sichtbar sind.

Technisch gesehen besteht der globale Deklarationsteil aus allen Deklarationen, die keinem lokaleren Kontext (Klasse, Prozedur) zugeordnet werden können. Insbesondere werden alle Deklarationen, die in Verarbeitungsblöcken ohne eigenen Kontext vorgenommen werden (in Ereignisblöcken und Dialogmodulen), und solche, die zwischen abgeschlossenen Verarbeitungsblöcken deklariert werden, dem globalen Kontext zugeordnet. Eine Ausnahme bilden die Ereignisblöcke zu den Ereignissen GET und AT SELECTION-SCREEN. Hier deklarierte Variablen sind nur innerhalb des Ereignisblocks gültig.

In einer ABAP-Anweisung kann man sich immer nur auf vorhergehende Deklarationen des aktuell sichtbaren Kontextes beziehen.

Globale Deklarationen an zentraler Stelle vornehmen

Platzieren Sie den globalen Deklarationsteil eines Programms zusammenhängend und an zentraler Stelle am Anfang des Programms.

Als globaler Deklarationsteil sollte nur der Bereich zwischen der programmeinleitenden Anweisung eines ABAP-Programms und der ersten Implementierung verwendet werden, und nur dort sollten globale Deklarationen in einer sinnvollen Reihenfolge vorgenommen werden. Nur dadurch ist garantiert, dass die für die globale Verwendung vorgesehenen Deklarationen auch in allen nachfolgenden Implementierungen verwendbar sind.

Insbesondere sollte es keine deklarativen Anweisungen in Kontexten geben, die keine lokalen Daten unterstützen (insofern diese noch verwendet werden). Diese erwecken beim Lesen des Programms andernfalls fälschlicherweise den Eindruck einer lokalen Gültigkeit, was zu einem falschen Verständnis des Programms führen kann.

Um diese Regel braucht man sich nur dann explizit zu kümmern, wenn man es mit anderen Programmtypen als Class- oder Interface-Pools zu tun hat. Bei diesen wird durch den Class Builder implizit vorgegeben, wo welche Deklarationen vorgenommen werden. Dies sind die Deklarationen der globalen Klasse bzw. des globalen Interface selbst sowie optionale lokale Datentypen, Klassen und Interfaces in Class-Pools. Ein Entwickler hat keinen direkten Zugriff auf das Rahmenprogramm eines Class- oder Interface-Pools. Daran ändert auch die Einführung des quelltextbasierten Class Builders nichts, da darin nur die Deklaration und Implementierung der globalen Klasse zu sehen sind.

Bei anderen Programmtypen, das heißt bei Subroutinen-Pools, Funktionsgruppen und ausführbaren Programmen hat ein Entwickler Zugriff auf das gesamte Rahmenprogramm. Wenn noch mit solchen Programmtypen gearbeitet wird, muss für die Einhaltung der Regel selbst gesorgt werden. Hierfür bietet sich insbesondere bei allen Programmen, die durch Include-Programme organisiert sind, das sogenannte Top-Include an, das genau für den globalen Deklarationsteil vorgesehen ist und entsprechend von der ABAP Workbench und vom ABAP Compiler unterstützt wird. Die ABAP Workbench bietet das automatische Anlegen und Einbinden des Top-Includes an. Der Compiler bezieht bei der Syntaxprüfung eines einzelnen Include-Programms das zugehörige Top-Include mit ein. Auf diese Weise lassen sich auch einzelne Include-Programme sinnvoll syntaktisch prüfen.

Das Top-Include soll, falls vorhanden, stets das erste Include-Programm sein, das von einem Rahmenprogramm eingebunden wird, und kann auch selbst wiederum weitere INCLUDE-Anweisungen enthalten. Das Top-Include und eventuell dort eingebundene Include-Programme dürfen nur Deklarationen und keine Implementierungen enthalten.

Wird weitestgehend mit ABAP Objects gearbeitet, enthält der globale Deklarationsteil bzw. das Top-Include bei strikter Einhaltung von obiger Regel im Wesentlichen nur noch die Deklarationen lokaler Klassen und Interfaces. Datentypen sollen nur noch im Rahmen von Klassen und Interfaces oder im ABAP Dictionary deklariert werden. Globale Datenobjekte sind nur noch für die Kommunikation mit klassischen Dynpros notwendig und sollten damit nur noch im Top-Include von Funktionsgruppen vorkommen, die klassische Dynpros verschalen.

Ausnahme

Obige Regel begründet sich hauptsächlich mit der programminternen Sichtbarkeit und Gültigkeit von Deklarationen. Sie gilt damit in voller Strenge nur für andere Programmtypen als Class-Pools. In Class-Pools spielen auch die Sichtbarkeit von außerhalb des Class-Pools und die daraus folgenden Abhängigkeiten eine Rolle.

Eine weitere Ausnahme von obiger Regel ergibt sich, wenn die lokalen Klassen eines Programms relativ unabhängige Einheiten sind und in ihren Implementierungen kein Bezug auf die Deklarationen anderer lokaler Klassen genommen wird. In diesem Fall können ihre Deklarations- und Implementierungsteile aus Gründen der Lesbarkeit auch direkt hintereinander aufgeführt werden.

Folgender Quelltext zeigt eine Funktionsgruppe zur Verschalung eines klassischen Dynpros nach Auflösung ihrer Include-Programme. Die beiden Dialogmodule enthalten Datendeklarationen, die zwar aussehen wie lokale Deklarationen, aber globale Gültigkeit haben. Statisch kann aber nur unterhalb der Deklaration auf ein solches Datenobjekt zugegriffen werden, sodass der Funktionsbaustein keinen Zugriff auf g_input_field und das PBO-Modul keinen Zugriff auf g_ok_code hat.

FUNCTION-POOL z_screen.

DATA g_start_value TYPE c LENGTH 20.

FUNCTION z_handle_screen.
*"------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" REFERENCE(i_start_value) TYPE csequence OPTIONAL
*"------------------------------------------------------
  g_start_value = i_start_value.
  CALL SCREEN 100.
ENDFUNCTION.

MODULE status_0100 OUTPUT.
  DATA g_input_field TYPE c LENGTH 20.
  g_input_field = g_start_value.
ENDMODULE.

MODULE user_command_0100 INPUT.
  DATA g_ok_code TYPE sy-ucomm.
  CASE g_ok_code.
    WHEN '...'.
       ...
  ENDCASE.
ENDMODULE.

Folgender Quelltext zeigt die Funktionsgruppe aus obigem Beispiel nach einer Verschiebung der globalen Deklarationen in einen zusammenhängenden globalen Deklarationsteil hinter der programmeinleitenden Anweisung. Das zusätzliche globale Datenobjekt g_start_value ist nicht mehr notwendig, und im PBO-Modul kann auf g_ok_code zugegriffen werden.

FUNCTION-POOL z_screen.

DATA: g_input_field TYPE c LENGTH 20,
      g_ok_code TYPE sy-ucomm.

FUNCTION z_handle_screen.
*"------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" REFERENCE(i_start_value) TYPE csequence OPTIONAL
*"------------------------------------------------------
  g_input_field = i_start_value.
  CALL SCREEN 100.
ENDFUNCTION.

MODULE status_0100 OUTPUT.
  CLEAR g_ok_code.
ENDMODULE.

MODULE user_command_0100 INPUT.
  CASE g_ok_code.
    WHEN '...'.
      ...
  ENDCASE.
ENDMODULE.

General Data in Customer Master   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 8799 Date: 20240606 Time: 121417     sap01-206 ( 154 ms )