Funktion Mit der Call-Anweisung können Sie aus einem GuiXT Script oder einem InputScript heraus eine Funktion aufrufen. Es kann sich entweder um einen in ABAP implementierten Funktionsbaustein handeln, der über die SAP-RFC-Schnittstelle aufgerufen wird, oder eine lokal (am Frontend) als dll-Funktion z.B. in VC++ implementierte Funktion.

Zu beachten: Die Call-Anweisung über RFC setzt die Komponente "InputAssistant" voraus.

Weitere Funktionen (wie automatische Formatkonvertierung, Bündelung von Aufrufen) bietet die "Open Call" Schnittstelle von GuiXT, siehe unten.

Beispiele

Call  "BAPI_USER_GET_DETAIL"   In.USERNAME="MEYER"   Out.LOGONDATA="UserLogonData"

Der Funktionsbaustein "BAPI_USER_GET_DETAIL" wird aufgerufen.

Call "ImgName" dll="utilities.dll" In="&F[Material]" Out="Datei"

Die Funktion "ImgName" der dll-Datei "utilities.dll" wird lokal aufgerufen.

Format RFC Aufruf

Call "Funktionsname" In.Name1="value1" In.Name2="value1" ... Out.Name1="vname1" Out.Name2="vname2"... Table.Name1="tab1" Table.Name2="tab2" ...    ... 

Zu beachten:

  • Die Gesamtzahl der Parameter (In + Out + Table) ist auf maximal 20 begrenzt.
  • Die Reihenfolge der Parameter: zuerst die "In" Parameter, dann die "Out" Parameter, dann die "Table" Parameter.

dll Aufruf
Call "Funktionsname" dll="dllname" In="Par1" In="Par2" ... Out="Par1" Out="Par2" ...

Alternatives Format: OpenCall Schnittstelle Call "Funktionsname" export.Name1="vname1" export.name2="vname2" ... import.Name3="vname3" import.Name3"vname4"   ....

Zu beachten:

  • Der Funktionsbaustein /GUIXT/Call  wird hierzu benötigt; Sie können ihn mit dem Transportauftrag sap.trans.guixtutilities.zip in Ihrem SAP-System einspielen
  • Erläuterungen und Beispiele finden Sie in den Artikeln unter Tips, Tricks and Samples
  • Die Gesamtzahl der Parameter (export + import) ist auf maximal 20 begrenzt.
  • Die Reihenfolge der Parameter: zuerst die "export" Parameter, dann die "import" Parameter.
  • Eine SAP DDIC Strukture ddicname kann durch export.name(ddicname)="vname" zusätzlich spezifiziert werden.
    Das ist nur erforderlich bei Import- order Table-Parametern  ohne vorgegebene Stuktur des aufgerufenen Funktionsbausteins. Die OpenCall-Schnittstelle überträgt dann die einzelnen Komponenten der GuiXT Variablen in die entsprechenden namensgleichen Komponenten der DDIC-Struktur.

Bei der Umstellung bestehender Call-Anweisungen auf die Open Call Schnittstelle bitte beachten:

  • Die Notation lehnt sich an die SAP-Syntax an und bezeichnet mit export diejenigen Parameter, die an den Funktionsbaustein exportiert werden und mit import diejenigen, die aus dem Funktionsbaustein importiert werden.
  • Sowohl bei export als auch bei import bei werden immer Variablennamen angegeben, nie direkte Werte
  • Strukturen und Tabellen werden ebenfalls mit  export und  import angesprochen; dabei GuiXT Strukturvariablen bzw. Tabellenvariablen verwenden
Format der OpenCall Schnittstelle für ABAP OO Remote Method Call Call "classname.methodname"  object="objname" export.name1="vname1" export.name2="vname2" ... import.Name3="vname3" import.name4="vname4"   ....

Ruft die Methode "methodname" des angegeben Objekts. Das Objekt muss der Klasse "classname" angehören. Falls object= nicht angegeben ist, wird eine statische Methode der KLasse aufgerufen.
Die Objekt-Id ist der Inhalt der GuiXT Variable V[objname]. Das Objekt selbst wird in der ABAP OO Umgebung anlegt. Die Zuordnung zwischen der Objekt-Id (GuiXT Kontext) und dem ABAP OO Objekt erfolgt automatisch in der OpenCall Schnittstelle.

Beispiel:

.......

// start a request bundle
Call BundledRequests="Start"   

// Create ALV object
Call cl_salv_table.factory export.t_table(sflights)="mytable" export.r_salv_table="alv"

// allow all standard functions
Call cl_salv_table.get_functions object="alv" export.value="functions"
Call cl_salv_functions_list.set_all object="functions" export.value="TRUE"

// Set Title
Call cl_salv_table.get_display_settings object="alv" export.value="display"
Call cl_salv_display_settings.set_list_header object="display" export.value="title"

// Set popup position
Call cl_salv_table.set_screen_popup object="alv" _
 
export.start_column="col1" export.start_line="row1" export.end_column="col2" export.end_line="row2"

// display popup
Call cl_salv_table.display object="alv"

// run all calls
Call BundledRequests -dialog

Zusatzoptionen
destination= Bei RFC. Die Optionen bitte unmittelbar hinter dem Namen des Funktionsbausteins angeben.

Aufruf eines Funktionsbausteins in einem anderen SAP-System. Die Destination muss in der Datei "saprfc.ini" enthalten sein.  Die Datei saprfc.ini liegt entweder in dem SAP- Workdirectory oder eine Umgebungsvariable RFC_INI benennt die Datei.
Weitere inzelheiten bitte der SAP-Dokumentaion entnehmen.

connection= Bei RFC. Die Optionen bitte unmittelbar hinter dem Namen des Funktionsbausteins angeben.

Aufruf eines Funktionsbausteins in einem anderen SAP-System. Die Verbindungssdaten werden direkt angegeben, z.B. connection="ASHOST=myhost.com SYSNR=00"
Benutzer, Passwort, Sprache  und Mandant werden, falls nicht bei connect= angegeben, automatisch ergänzt.

-try Bei RFC. Die Optionen bitte unmittelbar hinter dem Namen des Funktionsbausteins angeben.

Falls der Funktionsbaustein mit einer Exception abbricht, wird keine Fehlermeldung an den Benutzer ausgegeben. Stattdessen wird in der Systemvariablen V[_exception] der Name der ausgelösten Exception zur Verfügung gestellt. Durch if Q[ok] kann nach Call abgefragt werden, ob der Funktionsbaustein normal beendet wurde. Beispiel:

Call "RPY_TABLE_READ"  -try  in.TABLE_NAME="&V[structid]" ..
if not Q[OK]
  Return "E: Struktur &V[structid] nicht im Data Dictionary gefunden" -statusline
endif

-currentuser Bei RFC. Die Optionen bitte unmittelbar hinter dem Namen des Funktionsbausteins angeben.

Der Aufruf wird mit dem gerade angemeldeten Benutzer durchgeführt, nicht mit dem im GuiXT Profile angegebenen RFC-Benutzer.

Bitte beachten: Bei Single Sign On erfordert diese Option spezielle SNC-Angaben im GuiXT Profile (RFC OPtions), zum Beispiel:
ifCurrentuser=Yes SCN_MODE=1 SNC_PARTNERNAME="p:CN=&database, O=myCompany, C=DE"
Details finden Sie in den Tips, Tricks and Samples unter "Remote Function Call (RFC)"

Call "RPY_TABLE_READ"  -currentuser  in.TABLE_NAME="&V[structid]" ..

-dialog Bei RFC. Die Optionen bitte unmittelbar hinter dem Namen des Funktionsbausteins angeben.

Der Aufruf wird so ausgeführt, dass Benutzerdialoge innerhalb der aufgerufenen Funktion möglich sind.

cache= Bei RFC. Die Optionen bitte unmittelbar hinter dem Namen des Funktionsbausteins angeben.

Möglich sind die Angaben cache="transaction", cache="session"  und cache="file". Wirkung: Es wird vor Ausführen des RFC geprüft, ob bereits ein Aufruf des Funktionsbausteins mit den gleichen Eingaben stattgefunden hat. Falls ja, werden statt des RFC Aufrufs die Rückgabewerte aus einem internen Cache gelesen und zurückgeliefert. Falls nein, wird der RFC ausgeführt; anschliessend werden die zurückgelieferten Daten im Cache vermerkt.

Als Eingabewerte zählen die mit in.xxx= angegebenen Werte plus alle Tabelleninhalte table.xxx=.

Wichtig: Falls eine Tabelle "abc" von dem Funktionsbaustein nicht verarbeitet, sondern nur zurückgeliefert wird, ist es sinnvoll, sie vor dem Aufruf durch Set text[abc] "" zu löschen, damit ihr Inhalt nicht zu den Cache-Eingabewerten dazugenommen wird. Das würde zwar nicht zu fehlerhaften Daten führen, die Qualität des Cache aber erheblich verschlechtern.

Als Ausgabewerte zählen die mit out.xxx= angegebenen Parameter plus alle Tabelleninhalte table.xxx=.

Die Gesamtlänge aller Eingabewerte inklusiv der Parameternamen ist im Cache auf 8000 Zeichen beschränkt. Bei längeren Werten (insgesamt) wird die cache= Angabe ignoriert.

Bei Angabe von cache="transaction" wird ein Cache verwendet, der pro Neuaufruf einer Transaktion zurückgesetzt wird. Das heisst, wenn der Benutzer eine Transaktion neu mit /N... oder aus dem Menü aufruft, werden alle Daten frisch gelesen.

Bei Angabe von cache="session"  wird dagegen ein separater Cache verwendet, der für alle Transaktionsaufrufe innerhalb eines Modus gültig ist.

Die Angabe von cache="file" wirkt nur in Verbindung VersionNumber. Das lokale Dateisystem wird als Cache verwendet, sodass auch nach Neuanmeldung die einmal gelesenen Werte zur Verfügung stehen.

Der Session-Cache ist sinnvoll für Werte wie Benutzereinstellungen oder Customizing-Daten, während der Transaktionscache für Anwendungsdaten wie Kundenadressen verwendet werden kann, die sich im Prinzip jederzeit ändern können, die aber während eines Transaktionsaufrufs nicht ständig nachgelesen werden müssen.

Für ein eigenes Rücksetzen des Cache können Sie ClearCallCache cache="transaction" und  ClearCallCache cache="session" verwenden. In der Einstiegsmaske einer Transaktion kann es sinnvoll sein, durch ClearCallCache cache="transaction" den Transaktionscache zurückzusetzen, falls der Benutzer auch z.B. durch F3 oder F12 aus einem anderen Maske der Transaktion auf das Einstiegsbild gelangen kann, ohne die Transaktion neu aufzurufen. In diesem Fall beginnt nämlich die SAP-Anwendung technisch keine neue Transaktion, sodass der bisherige Transaktionscache noch gültig ist. 

Um die über cache="file" gemerkten Werte zu löschen, bitte  ClearCallCache cache="file" verwenden oder die VersionNumber erhöhen.

Weitere Zusatzoptionen für den Fall der
Open Call Schnittstelle
-bundle Bündelt diesen Call mit weiteren zu einem einzigen RFC-Aufruf, sodass nur ein einziger Netzwerk-Kommunikationsschritt stattfindet.
BundledRequests="start" Setzt die -bundle Option für alle nachfolgenden Calls
BundledRequests="stop" Beendet das Setzen der -bundle Option für alle nachfolgenden Calls
BundledRequests Durch Call BundledRequests werden alle bisherigen mit der Option -bundle versehenen Calls nun gebündelt verarbeitet
-parallelProcessing Zusatz bei Call BundledRequests: Die Verarbeitung auf dem SAP Applikationsserver erfolgt parallelisiert. Je nach Anzahl x der im SAP definierten Maximalzahl von Alternativmodi wird die Verarbeitung in x-1 Prozessen durchgeführt. Der Standard im SAP-System ist x=6, die Maximalzahl x=16. Die Reihenfolge der Abarbeitung ist dabei nicht festgelegt.
serverGroup= Zusatz bei Call BundledRequests: Die Verarbeitung erfolgt auf der angegebenen, im SAP System definierten Gruppe von Applikationsservern (SAP-Transaktion: RZ12)
importFromBundle= Die Resultate des Calls mit der angegebenen Nummber 1,2,3... werden aus der gesamten Resultatmenge gelesen und in die bei import= angegebenen Variablen gestelltlt. Durch Q[ok] kann abgefragt werden, ob ein Call mit der angegebenen Nummer im Call-Bündel existiert.

Durch importFromBundle="*" werden alle Call-Resultate importiert.

Falls noch kein  Call BundledRequests durchgeführt wurde, wird dieser implizit durch die erste Call importFromBunmdle=Anweisung ausgelöst.
DeleteBundledRequest Die gesamte Resultatmenge des vorhergehenden gebündelten Aufrufs wird gelöscht.
Implizit löscht auch jeder folgende gebündelte Zugriff die Resultatmenge des vorhergehenden Bündels.
RFC Aufruf Parameterübergabe

Call
"funktionsname" In.Name1="value1" In.Name2="value2" ... Out.Name1="vname1" Out.Name2="vname2" ...   Table.Name1="tab1" Table.Name2="tab2"

Restriktionen

  • Die übergebenen Tabellen dürfen zeichenartige und dezimal gepackte Werte enthalten (ABAP-Typen C, P, N, D, T)
  • Die Breite der Tabelle ist auf 4000 Zeichen beschränkt (beliebig viele Zeilen sind möglich). Sie können in einem Call pro Tabelle die benötigte Breite aber selbst auf einen Wert zwischen 1 und 32000 setzen durch den Zusatz (width:xxxx) hinter dem Tabellennamen:
    Table.Name1(width:8000)="tab1"

Handhabung von Tabellen

  • Tabellen werden wie Langtexte behandelt. Sie können z.B.  die Anweisung CopyText benutzen. 
  • Tabelleninhalte werden in beiden Richtungen übertragen
  • Sie können Data Dictionary Strukturen verwenden oder direkt mit Offsets auf Teilfelder zugreifen
  • Bei Teilfeldern im ABAP-Format P (dezimal gepackt) bitte die Optionen -pack beim Setzen von Werten und -unpack beim Lesen von Werten verwenden. Bei symbolischen Angaben (Data Dictionary Struktur) wird die Option -pack bei Setzen eines Wertes automatisch ergänzt.

Beispiel 1:
Wir benutzen den SAP-Standardfunktionsbaustein "BAPI_USER_GET_DETAIL", um die Benutzergruppe (Informationen aus Benutzerstammsatz) zu lesen:

Call  "BAPI_USER_GET_DETAIL"   In.USERNAME="&V[_user]"   Out.LOGONDATA="UserLogonData"
Set V[UserGroup] "&V[UserLogonData](BAPILOGOND-CLASS)"

Danach steht in der Variablen V[UserGroup] die Benutzergruppe zur Verfügung.

Erläuterung (vergleichen Sie die Schnittstellendefinition in Transaktion SE37):

  • Den Importing-Parameter USERNAME besetzen Sie mit der Systemvariable  &V[_user]
  • Zurückgeliefert wird der Exporting-Parameter LOGONDATA  im Parameter  &V[UserLogonData]
  • Laut Definition der Struktur BAPILOGOND enthält das Teilfeld CLASS die Benutzergruppe

Beispiel 2:
Ändern eines Benutzerparameters durch Lesen aller Parameter und Rückschreiben aller Parameter

// User parameter id to be changed, and new value:
Set
V[Paramid] "ND9"
Set V[Paramva] "Printer2400"

// Read user parameters
Call "BAPI_USER_GET_DETAIL" in.USERNAME="&V[_user]" table.PARAMETER1="ipt"

// Clear output parameter table
Set text[opt] ""

// "found" indicator
Set V[found] ""

// Loop through all user parameters
Set V[i] 1

Label next_parameter
CopyText fromText="ipt" toString="p" line="&V[i]"

if Q[ok]

  Set V[parid] "&V[p](BAPIPARAM1-PARID)"
    if V[parid=&V[Paramid]]
       Set V[p](BAPIPARAM1-PARVA) "&V[Paramva]"
       Set V[found] "X"
endif

// add parameter to new parameter table
CopyText fromString="p" toText="opt" -appendline

// next line
Set V[i] &V[i] + 1
goto next_parameter

endif

// parameter not found: add parameter line
if not V[found=X]
  Set V[p](BAPIPARAM1-PARID) "&V[Paramid]"
  Set V[p](BAPIPARAM1-PARVA) "&V[Paramva]"
  CopyText fromString="p" toText="opt" -appendline
endif

// Write back parameters
Call "BAPI_USER_CHANGE" in.USERNAME="&V[_user]" in.PARAMETERX="X" table.PARAMETER1="opt"

dll-Aufruf Die Funktion wird bei z.B. 2 IN und 3 OUT-Parametern vom Typ

__declspec(dllexport) int funcname(char* p1, char*p2, char* p3, char* p4, char* p5)

definiert. Alle Parameter (In= und Out=) werden in der angegebenen Reihenfolge übergeben. Die maximale Länge jedes einzelnen Strings beträgt 4000 Zeichen. Bitte achten Sie darauf, in dem Script genügend viele Parameter anzugeben, sonst greift die dll-Funktion auf eine ungültige Adresse zu.

Tipps
& Tricks
  • Zum Testen des Aufrufs eines ABAP Funktionsbausteins empfiehlt sich die Testumgebung der ABAP Workbench. Sie können mit
    ProcessingOption debugRFC="On"
      Call ...
    ProcessingOption debugRFC="Off"
    den RFC-Aufruf im Debug-Modus durchführen.
     
  • Der für den RFC verwendete RFC Benutzername und das Passwort sind im GuiXT-Profile hinterlegt (Passwort ist verschlüsselt).
     
  • Die Komponente "GuiXT Controls" unterstützt den Aufruf von Funktionen, die in VBScript, JavaScript, VB.NET oder C# implementiert sind.
Komponente GuiXT + InputAssistant
Fall dll: nur GuiXT nötig