Purpose |
With
Call
you can call a
function from a GuiXT script or from an InputScript. The function can
either be an SAP function module on the SAP application server,
or a local dll-function (on the frontend PC), implemented in VC++ or a
similar language. For function modules we use SAP's RFC (Remote Function Call)
interface technology. Please observe that the
Call-command
via RFC requires the component "InputAssistant".
Further functions (like
automatic format conversion, bundling of calls) are provided by the
"Open Call" interface of GuiXT, see below.
|
Examples |
Call
"BAPI_USER_GET_DETAIL"
In.USERNAME="MEYER"
Out.LOGONDATA="UserLogonData"
The SAP function module
"BAPI_USER_GET_DETAIL"
is called via RFC.
Call
"ImgName"
dll="guiexits"
In="&F[Material]"
Out="Matfilename"
The dll-function
ImgName
is called locally.
|
Format |
RFC call
Call
"funcname"
In.Name1="value1"
In.Name2="value2"
...
Out.Name1="vname1"
Out.Name2="vname2"
... ...
Table.Name1="tab1"
Table.Name2="tab2"
...
dll call:
Call
"funcname"
dll="dllname"
In="par1"
In="par2"
... Out="par1"
Out="par2"
...
Please observe:
- Up
to 20 parameters (In+Out+Tables) are possible
- You first name the
"In" parameters, then "Out", then "Table"
|
Format of
the OpenCall Interface |
Call
"functionname"
export.name1="vname1"
export.name2="vname2"
... import.name3="vname3"
import.name4="vname4"
....
Please note:
-
The function module
/GUIXT/Call is required for this; you can import it into your SAP
system with the transport request
sap.trans.guixtutilities.zip
-
You can find explanations and examples in the articles
Tips, Tricks and Samples
- The total number
of parameters (export
+ import)
is limited to a maximum of 20
-
The order of the parameters: first the "export" parameters, then the
"import" parameters.
-
An SAP DDIC structure
ddicname
can be specified with
export.name(ddicname)="vname".
This is only needed for an import parameter or for a table
without structure definition in the called function interface. If
specified, the interface maps the structure components by name to
the corresponding fields of the DDIC structure.
When converting existing call instructions to the Open Call interface,
please note the following:
-
The notation is based on the SAP syntax and designates as
export those parameters that are
exported to the function module and as
import those that are imported from the
function module.
-
export
as well as
import always specify variable names,
never direct values
-
Structures and tables are also addressed with
export
and
import; use GuiXT structure variables or
table variables here.
|
Format of
the OpenCall Interface for ABAP OO Remote Method Call |
Call
"classname.methodname"
object="objname"
export.name1="vname1"
export.name2="vname2"
... import.Name3="vname3"
import.name4="vname4"
....
Calls the method "methodname" of the specified object. The object
must belong to the class "classname". If object= is not specified, a
static class method is called. The object ID is the content of the
GuiXT variable V[objname]. The object itself is created in the ABAP OO
environment. The mapping between the specified object ID (GuiXT context)
and the ABAP OO object is automatically performed in the OpenCall
interface.
Example:
....
// 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
|
Additional
options |
destination= |
In the
case of RFC. Please specify the options immediately after the function
name.
The destination
must be described in the file saprfc.ini; please
see the SAP RFC documentation for details. The file saprfc.ini is either
in the SAP GUI working directory "...\SAPworkdir", or you use the environment
RFC_INI to name the saprfc.ini file.
|
connection= |
In the
case of RFC. Please specify the options immediately after the function
name.
Sets the RFC
connection string for the given call. Example:
connection="ASHOST=myhost.com SYSNR=00". The user, password,
language and client are automatically added, if not specified in
the given string. |
-try |
In the
case of RFC. Please specify the options immediately after the function
name.
If
the function ends with an "exception", no error message is shown
to the user. Instead, the system variable
V[_exceptionid]
obtains the name of the exception and
V[_exception] a text. With
if
Q[ok]
you can query, after
call,
if the function has ended normally. Example:
Call
"RPY_TABLE_READ"
-try in.TABLE_NAME="&V[structid]"
...
if not Q[OK]
Return "E: Structure &V[structid]
not found in data dictionary" -statusline
endif
If the function module issues an error message in addition to the exception, the information on error handling is available in the following fields:
V[_rfcmsgtype] Message type, usually 'E' V[_rfcmsgid] Message area V[_rfcmsgno] Message number V[_rfcmsgv1] Variable 1 V[_rfcmsgv2] Variable 2 V[_rfcmsgv3] Variable 3 V[_rfcmsgv4] Variable 4
Example:
Call "TAX_NUMBER_CHECK" in.COUNTRY="&V[country]" in.TAX_CODE_1="&V[taxcode]" in.NATURAL_PERSON_FLAG=""
if V[_exceptionid=NOT_VALID]
Message type="E" id="&V[_rfcmsgid]" number="&V[_rfcmsgno]" _ var1="&V[_rfcmsgv1]" var2="&V[_rfcmsgv2]" var3="&V[_rfcmsgv3]" var4="&V[_rfcmsgv4]" -statusline
Return
endif
|
-ng>currentuser |
In the
case of RFC: Please specify the options immediately after the function
name.
The
call is executed with the user that is currently logged on.
Please note:
For Single Sign On, this option requires special SNC
specifications in the GuiXT profile (RFC Options), for example: ifCurrentuser=Yes
SCN_MODE=1 SNC_PARTNERNAME="p:CN=&database, O=myCompany, C=US" For details, see the Tips,
Tricks and Samples section under "Remote Function Call (RFC)".
Call
"RPY_TABLE_READ"
-currentuser
in.TABLE_NAME="&V[structid]"
...
|
-dialog |
In the
case of RFC: Please specify the options immediately after the function
name.
The
call is executed in a way that allows user dialogs.
|
cache= |
In the
case of RFC: Please specify the options immediately after the function
name.
You
may specify
cache="transaction",
cache="transaction" or
cache="file".
Effect: Before executing the RFC GuiXT checks whether a previous
call of the same function has already used the same input parameters.
If yes, the output parameters are read from an internal cache instead
of executing the RFC. If no, the RFC is executed and its output
parameters are stored into the internal cache.
The input parameters
are the values specified with
in.xxx=
plus the content of all tables specified with
table.xxx=.
If a table
"abc"
is not read by the called function module, but returned only, you
should clear it before executing the Call, for example with
Set text[abc]
"".
Otherwise the table content becomes part of the cache key, not leading
to wrong results, but to a less efficient cache.
The output parameters
are the variables specified with out.xxx= plus the content of all
tables specified with
table.xxx=.
If the total cache
key length is more than 8000 bytes, the
cache=
option
will be ignored.
With
cache="transaction"
you make use of a cache
that is cleared by GuiXT for each new transaction call. This means
that for a transaction that the user starts with
/N...,
or by choosing it in the SAP menu, all data will be freshly read
from the SAP system. With
cache="session"
you make use of
a cache that is kept during the session for all transactions within
one SAP mode.
The session cache
cache="session"
can
be used for user profile data or for customizing data, whereas the
transaction cache is well suited for application data such as a
customer address, which in principle can be changed at any time,
but does not require to be read several times during one transaction.
The file system
cache
cache="file"
works in combination
with
VersionNumber.
The local file system
is used as RFC cache so that the result values of the RFC are
available even after a new SAP GUI logon.
You can clear the cache
on your own using the
ClearCallCache cache="transaction"
and
ClearCallCache cache="session"
command. For example,
you may use
ClearCallCache cache="transaction"
in the initial screen
of a transaction, if the user is able to return to the initial screen
with F3 or F12 from within the transaction instead of entering
/N...
. In this case (F3 or F12) the SAP application technically does
not start a new transaction and thus the transactions cache is not
cleared by GuiXT.
In order to reset
the file system cache. either use
ClearCallCache cache="file"
or increase the
VersionNumber.
|
|
Additional
options for the case of the Open Call interface
|
-bundle |
Bundles this call with other calls to form a single RFC call, so
that only one single network communication step takes place |
BundledRequests="start" |
Sets the
-bundle option for all subsequent calls |
BundledRequests="stop" |
Stops setting the
-bundle option for all subsequent calls |
BundledRequests |
Call
BundledRequests now bundles all previous calls
specified with the -bundle option and processes them on
the SAP application server |
-parallelProcessing |
Addition for
Call
BundledRequests:
Depending on the number x of the maximum number of alternative
modes defined in SAP, processing is carried out in x-1
processes. The standard in the SAP system is x=6, the maximum
number x=16. The sequence of processing is not defined. |
serverGroup= |
Addition for
Call
BundledRequests: Processing takes place on
the specified group of application servers defined in the SAP
system (SAP transaction: RZ12) |
importFromBundle= |
The
results of the call with the specified number 1,2,3... are read
from the total result set and placed in the variables specified
as import.
if Q[ok]can
be used to query whether a call with the specified number exists
in the call bundle.
With
importFromBundle="*" all call results are
imported.
If no
Call
BundledRequests has yet been executed, this is
implicitly triggered by the first
Call
importFromBundle= statement.
|
DeleteBundledRequest |
The
entire result set of the previously bundled calls is deleted.
Each bundled
Call
also implicitly deletes the result set of the previous bundle. |
|
Calling an
SAP function module |
Passing
parameters
Call
"funcname"
In.Name1="value1"
In.Name2="value2"
... Out.Name1="vname1"
Out.Name2="vname2"
... Table.Name1="tab1"
Table.Name2="tab2"
...
Restrictions
- Tables may consist of
character-type or packed decimal fields fields (ABAP-Types C, P, N,
D, T)
- The default table width
is 4000. No restriction on the number of lines. If necessary, you can
specify a different width between 1 und 32000 for each table in the
call statement:
Table.Name1(width:8000)="tab1"
Handling of tables
- Tables are handled in
InputScripts like texts. For example, you can use the
CopyText
statement.
- They are transferred in
both directions
- You may use data dictionary based structures
to address single fields within a structure
Example 1:
We call the SAP standard function BAPI_USER_GET_DETAIL"
to read the user group (User master record).
Call
"BAPI_USER_GET_DETAIL"
In.USERNAME="&V[_user]"
Out.LOGONDATA="UserLogonData"
Set
V[UserGroup]
"&V[UserLogonData](BAPILOGOND-CLASS)"
Now the variable
V[UserGroup]
contains the SAP user
group.
Explanation (see also the interface
definition in transaction SE37):
- The system variable
&V[_user] is passed as importing
parameter
USERNAME
- The variable
&[UserLogonData]
obtains the value
of the exporting parameter
LOGONDATA
- According to structure
definition
BAPILOGOND
you find the user
group in component CLASS
Example 1:
We change a user parameter by importing and exporting all user
parameters via BAPIs
//
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"
|
Calling a dll
function |
The function
declaration is as follows (example with 2 IN parameters and 3 OUT parameters):
__declspec(dllexport) int funcname(char*
p1, char*p2, char* p3, char* p4, char* p5)
All parameters (IN and OUT)
are passed in the order specified in the script. The maximum length of each
string is 4000 characters. Please specify all parameters in your script,
otherwise the dll-function gets an address exception.
|
Tips
& Tricks |
- In order to debug an
RFC call with the ABAP workbench you may use
ProcessingOption debugRFC="On"
Call ...
ProcessingOption debugRFC="Off"
- You can specify the RFC
user and password in the GuiXT profile. The password is stored in the GuiXT profile in encrypted format.
- The "GuiXT Controls"
component supports calling functions that are implemented in
VBScript, JavaScript, VB.NET or C#.
|
Components |
GuiXT +
InputAssistant (with dll: just GuiXT necessary) |