Ansicht
Dokumentation

ABENINTERN_EXTERN_PROC_CALL_GUIDL - INTERN EXTERN PROC CALL GUIDL

Fill RESBD Structure from EBP Component Structure   BAL Application Log Documentation  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Interne und externe Prozeduraufrufe

Beim Aufruf einer Prozedur unterscheidet man zwischen internem und externem Prozeduraufruf. Beim internen Aufruf wird eine Prozedur desselben Programms gerufen, während beim externen Aufruf eine Prozedur eines anderen Programms gerufen wird. Der grundlegende Unterschied zwischen internem und externem Prozeduraufruf besteht darin, dass bei einem externen Aufruf das zugehörige Programm möglicherweise erst geladen werden muss, während es bei einem internen Aufruf natürlich stets bereits geladen ist. Mögliche externe Aufrufe, die zum Laden eines Programms führen können, sind Aufrufe von:

• Methoden globaler Klassen in Class-Pools

• Funktionsbausteine in Funktionsgruppen

• Unterprogrammen in allen Programmen, die Unterprogramme enthalten können (PERFORM...IN PROGRAM)

• Methoden lokaler Klassen, wobei der Name der Klasse dynamisch über einen absoluten Typnamen (\PROGRAM= ... \CLASS=...\) angegeben wird

Die in eine interne Sitzung geladenen Programme bilden dort Programmgruppen. Es gibt immer eine Hauptprogrammgruppe und die Möglichkeit mehrerer Zusatzprogrammgruppen. Jede Programmgruppe enthält ein Hauptprogramm und eventuelle, durch externe Verwendung hinzugeladene Programme. Das Hinzuladen geschieht nicht ausschließlich durch Aufrufe, sondern es sind auch andere Bezüge auf Komponenten externer Programme möglich, wie zum Beispiel ein Bezug auf einen sichtbaren Datentyp einer globalen Klasse. Das Hinzuladen geschieht nicht ausschließlich durch Aufrufe, sondern es sind auch andere Bezüge auf Komponenten externer Programme möglich, wie zum Beispiel ein Bezug auf einen sichtbaren Datentyp einer globalen Klasse.

Wird in einer extern aufgerufenen Prozedur auf gemeinsame Ressourcen der Programmgruppe zugegriffen, ist es relevant, zu welcher Programmgruppe das zugehörige Programm hinzugeladen wurde. Ob ein Programm beim Laden eine eigene Programmgruppe bildet oder zu einer existierenden Programmgruppe hinzugeladen wird, hängt im Wesentlichen vom Programmtyp ab:

• Class-Pools und Funktionsgruppen und damit die externen Aufrufe von Methoden globaler Klassen oder von Funktionsbausteinen führen beim Laden immer zu einer neuen Programmgruppe.

• Werden Unterprogramme oder die Methoden lokaler Klassen anderer Programmtypen als Class-Pools und Funktionsgruppen extern aufgerufen, werden die Programme beim Laden in die Programmgruppe des Aufrufers hinzugeladen.

Nur geeignete Prozeduren extern aufrufen

Rufen Sie nur solche Prozeduren extern auf, die dafür vorgesehen sind. Die Methoden globaler Klassen und Funktionsbausteine sind für den externen Aufruf vorgesehen. Unterprogramme und die Methoden lokaler Klassen sind nicht für den externen Aufruf vorgesehen.

Die einzigen Prozeduren, die für den externen Aufruf vorgesehen sind, sind die sichtbaren Methoden globaler Klassen und Funktionsbausteine. Die Rahmenprogramme dieser Prozeduren sind immer Hauptprogramme ihrer Programmgruppen, und es ist immer festgelegt, dass die Prozedur mit den Ressourcen dieser Programmgruppe arbeitet.

Der externe Unterprogrammaufruf und der dynamische Aufruf von Methoden in lokalen Klassen eines anderen Programms sind dagegen problematisch. In der Regel sind Unterprogramme und lokale Klassen für die interne Verwendung in ihrem Programm vorgesehen. Es kann bei der Entwicklung nicht antizipiert werden, dass sie auch von außen aufgerufen werden. (Unproblematisch ist es dagegen, wenn ein bereits geladenes Programm bewusst eine Referenz auf ein Objekt einer lokalen Klasse an ein anderes Programm übergibt.) Sie sollten daher immer wie private Komponenten ihres Programms behandelt werden, auch wenn sie technisch gesehen öffentlich sind.

Darüber hinaus liegt die Zuordnung zu einer bestimmten Programmgruppe nicht statisch fest. Da die Verwendungsreihenfolge von Benutzeraktionen oder Dateninhalten abhängen kann, kann das Programm der gerufenen Prozedur einmal zur Hauptprogrammgruppe und ein anderes Mal zu einer Zusatzprogrammgruppe gehören. Dadurch ist nicht festgelegt, zu welcher Programmgruppe die gemeinsam genutzten Ressourcen gehören. Dabei handelt es sich um:

• Klassische Dynpros (inklusive Selektionsbildern und klassischen Listen) und GUI-Status

Diese werden innerhalb einer Programmgruppe stets gemeinsam verwendet, und zwar immer die des Hauptprogramms innerhalb dieser Programmgruppe. So ruft die Anweisung CALL SCREEN innerhalb einer extern gerufenen Prozedur stets ein Dynpro des Hauptprogramms der Programmgruppe, und nicht ein Dynpro der die Prozedur umgebenden Kompilationseinheit. Die Reaktion auf Benutzereingaben in dem so gerufenen Dynpro findet ebenfalls im Hauptprogramm der Programmgruppe statt.

• Schnittstellen-Arbeitsbereiche

Schnittstellen-Arbeitsbereiche werden über die Anweisungen TABLES, NODES als Tabellenarbeitsbereiche oder über das obsolete DATA ... COMMON PART definiert, pro Programmgruppe nur einmal angelegt und von dem Hauptprogramm sowie den hinzugeladenen Zusatzprogrammen gemeinsam verwendet.

Hinweis

Abgesehen von der Warnung vor dem dynamischen Aufruf von Methoden lokaler Klassen anderer Programme, soll diese Regel hauptsächlich das Problembewusstsein beim Umgang mit vorhandenen Programmen wecken. In neuen Programmen ist das Anlegen neuer Unterprogramme und die Nutzung gemeinsamer Ressourcen ohnehin weitestgehend obsolet. Lediglich die Verwendung von klassischen Dynpros oder Selektionsbildern (und damit ebenfalls von GUI-Status und Tabellenarbeitsbereichen) kann noch zu den genannten Problemen führen.

Beispiel

Das Beispiel in folgendem Quelltext demonstriert die Zuordnung von Schnittstellen- Arbeitsbereichen zu Programmgruppen bei externen Unterprogrammaufrufen. Der im Programm sapssubr deklarierte Tabellenarbeitsbereich dbtab wird entweder mit sapmprog oder saplfugr geteilt. Wenn share den Wert 'FUGR' hat, nutzen saplfugr und sapssubr den Tabellenarbeitsbereich gemeinsam. Andernfalls teilen ihn sich sapmprog und sapssubr. Man kann sich also nicht auf eine bestimmte Zuordnung verlassen.

***********************************
PROGRAM sapmprog.
TABLES dbtab.
...
IF share = 'FUGR'.
  CALL FUNCTION 'FUNC'.
ENDIF.
...
PERFORM sub IN PROGRAM sapssubr.
***********************************

***********************************
FUNCTION-POOL saplfugr.
TABLES dbtab.
...
FUNCTION func.
  PERFORM sub IN PROGRAM sapssubr.
ENDFUNCTION.
***********************************

***********************************
PROGRAM sapssubr.
TABLES dbtab.
...
FORM sub.
  ...
ENDFORM.
***********************************

General Material Data   BAL Application Log Documentation  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 8147 Date: 20240523 Time: 183847     sap01-206 ( 172 ms )