Understand the GuiXT Open Call Interface
statement allows us to call up an SAP function module, e.g. a BAPI,
via the SAP RFC interface (Remote Function Call). The "Open
Call Interface" enriches the basic Call function providing a
number of useful extensions.
The function module
the central entry point of the Open Call Interface, is needed in the SAP
system. You can import
/GUIXT/Call via the
(click to open up the .zip file).
The notation is slightly different compared
to the normal Call, thereby indicating that you are using the Open Call
The Open Call Interface uses GuiXT table variables.
See the following articles for examples and
a detailed explanation of the various possibilities.
- Automatic data conversion
on the UI level where all fields are shown and expected in external
format; so it is more appropriate to use this format instead of
having to apply the SAP conversion rules. For example, you can pass a
customer number as "1284" instead of "0000001284".
This also works for more complex conversions, for example when
you pick up a functional location "SWC-EC" from a field on the
screen and want to call up the function
BAPI_FUNCLOC_GETDETAIL to read some details. With the standard Call
you need to pass the internal value "?0100000000000005483", i.e. you
first need to call up the appropriate SAP conversion function. With
the Open Interface you simply pass "SWC-EC". The same applies in the
opposite direction, for example when you use BAPI_FUNCLOC_GETLIST in
order to receive a list of functional locations, you will obtain
"SWC-EC" in the result table and not "?0100000000000005483" as in
the standard call.
The automatic conversion is applied to
single fields, fields in structures and to table columns, and is
applied in both directions.
- Column selection for result tables and structures
Some BAPIs return tables with a large number of columns. For
example, the structure BAPISDITBOS which is used to return a table
of customer sales order items consists of 237 columns. In a concrete
GuiXT application you may need 24 columns only. The Open Call
Interface reduces the network traffic since it transports these 24
columns instead of all 237.
- Bundle multiple calls
You may bundle
many calls into one. For example, let us assume that you have a
table with 200 sales orders and you want to apply a BAPI for each
sales order, reading additional data. If the RFC network
overhead takes 20ms and the internal runtime of the call is 2ms, it
will take 4.4 seconds to execute all calls. When you bundle the
calls it will be completed in 0.42 seconds.
- Parallel processing
You can switch on
parallel processing for the bundled calls. The calls will then be
internally distributed to several SAP work processes. This
approach makes sense for long-running calls which can be
For example, when you have 10 calls each needing
around 12 seconds, you need 2 minutes with sequential processing
versus 24 seconds with parallel processing in 5 work processes (SAP
standard configuration). For special cases you can configure more
parallel modes in SAP (up to 15) and come down to 12 seconds for all
calls. It is even possible to use multiple application servers in
parallel, although this is probably rarely needed in GuiXT
- Avoid the metadata overhead of the NWRFC interface
The SAP NWRFC interface, in contrast to the legacy "classic" RFC,
needs meta data which describe the function module interface.
Reading the metadata is done the first time a function module is
called after starting SAP GUI; this can take several seconds for
each function module. The Open Call Interface avoids this overhead,
since the functions are called internally by /GUIXT/CALL.
- Avoid problems with non-ANSI characters in small
If you want to set e.g. "ÖX" into a 2 character
field of a BAPI structure, only "Ö" will be transmitted in the
standard call, since GuiXT uses the SAP-UTF-8 structures which
reserve one byte only for each character. This problem no longer
occurs with the Open Call Interface.
- Call up function modules which are not
Since the Open Call Interface calls up
the function modules internally, not via RFC, it is not required
that they are marked as "remote-enabled" in transaction SE37. For
security reasons the Open Call Interface nevertheless checks the
user rights for calling the function module remotely so that you can
control which function modules should be callable by GuiXT
(authorization object S_RFC).
There exist many SAP function modules which are useful in GuXT
applications but are not released for RFC. With the Open Call
Interface it is no longer necessary to create "wrapper" functions
in order to call such function modules from GuiXT, since
/GUIXT/Call plays the role of a generic wrapper function.
There is also a "Released" attribute in SE37 which is
independent of "RFC enabled". "Released" means "Released for
customer's use". SAP discourages you from using function modules
that are not "Released", since such functions can be changed without
notice and without SAP taking over any responsibility or providing
OSS support, unless the problem occurs in a standard application.
For details see OSS note 109533.
On the other hand, even
well-documented and popular function modules such as
MATERIAL_UNIT_CONVERSION are not "released". Some statistics: There
exist around 500 000 function modules, 8 000 of them are released.
Of 48 000 RFC enabled functions 4 000 are released. There are
around 5 000 BAPIs and only 3000 are released, which looks like a
'contradictio in se'. On the other hand, there exist
4 000 function modules which are "Released" but not "RFC enabled".
For example, the function modules READ_TEXT and SAVE_TEXT
are "Released" and well-documented. But they are not RFC
enabled. There exist the counterparts RFC_READ_TEXT and
RFC_SAVE_TEXT which are RFC enabled, but they have a different
interface, no documentation in SE37 and are not "Released". The Open
Call Interface gives you direct access to the functions READ_TEXT