With
Callyou 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.
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
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:
GuiXT
....
// 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
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)".
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.
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.
deleteBundledRequests
The
entire result set of the previously bundled calls is deleted.
Each bundled
Call
also implicitly deletes the result set of the previous bundle.
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).
GuiXT
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
GuiXT
// 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 Call
The function is defined, for example, with 2 IN and 3 OUT parameters of the type
All parameters (in= and out=)
are passed in the specified order. The maximum length of each
individual string is 4000 characters. Please make sure to specify enough parameters in the
script, otherwise the dll function will access an invalid address.
Example 1: Call "alphanum"
Adds leading 0000... to a numeric field.
Parameters:
In: The string to which the 0000... should be prefixed
Typically, when generating ASCII text files, double quotation marks are placed around the characters.
In SAP ERP, these quotation marks are undesirable.
You can download and freely use or extend the DLL and the source code.
Please note that you choose the correct target platform in the project depending on whether you want to build for the 32bit or 64bit
version of GuiXT or the SAP GUI.