Invoke an ABAP OO method remotely
ABAP OO does not support RMI (Remote Method Invocation) in a similar way as is available for function calls (Remote Function Call interface, RFC). The GuiXT Open Call interface fills this gap and provides a convenient way to call most ABAP OO methods remotely.
The SAP class library contains more than 200 000 classes and some of them can be useful in GuiXT applications. Please keep in mind that SAP may change all methods with the next upgrade, since apparently there exists no concept to declare classes as released for external usage. For frequently used classes such as the ALV classes, which have been in use for many years, only compatible further developments are to be expected on the part of SAP.
A description of the GuiXT "Call" notation can be found in the Call documentation. We describe some additional aspects here.
1. General approach to handling ABAP OO in GuiXT
GuiXT supports only string type variables, no number types, references or pointers, not to mention objects and classes. This simple approach is kept when calling ABAP OO methods.
In GuiXT, an ABAP OO object is always addressed by a freely assignable name, for example "item1". The name is assigned to an ABAP OO object at ABAP level by the GuiXT interface. There is no knowledge on GuiXT level that a variable e.g. V[c1] with the content "item1" refers to an ABAP object of a certain class.
The object names are managed separately for each class, i.e. two objects with the name "item1" can exist, one of class "cl_A" and one of class "cl_B". The class name is specified explicitely in each "Call" statement.
2. Calling static methods
Static methods can be called independently of a particular instance of this class. The GuiXT notation is identical to a function call, with the function name replaced by "classname.methodname":
Call "classname.methodname" export.name1= ... import.name2= ...
All options of the Call statement such as -try, -dialog ... can be used, including the bundling of calls.
calculate week number
You can test methods calls (at least simple ones) in transaction SE24:
3. Creating an object of a certain class
To create a new object call the "constructor" method of the class and pass a unique object name as parameter "result". This will create an object of the specified class which you can address by its name in the following Call statements.
// read text for company code 5400 Call
... Passing an object name without creating the instance first is also possible. The object is then created on the fly by the interface. This automatic creation does not work if the constructor method of the class requires further parameters.
Another way to create objects is to call a method that creates the object and returns the object reference ("factory" methods). In this case you also pass the desired object name with "export=".
// Create ALV object
Set V[alv] "alv"
Call "cl_salv_table.factory" export.t_table="mytable" export.r_salv_table="alv"
4. Calling instance methods
For instance methods you add the object= parameter and specify a GuiXT variable whose content is the object name:
Call "classname.methodname" object="objvarname" _
export.name1=" ... import.name2= ...
Note that you do not pass the object name as a string but the name of a GuiXT variable which contains the object name.
// read text for company code 5400 using the
general text identifier class
Call "cl_text_identifier.constructor" export.result="ti"
5. Always use "export=" to pass object names
Intuitively one tends to write
Call "cl_text_identifier.constructor" import.result="ti" // wrong!
i.e. to use "import=", because the class constructor method returns the new object reference. This would be correct at the ABAP level, but in the additional GuiXT interface layer the direction is reversed in the case of object references: we supply the object name and the interface will associate this name with the new object reference:
Call "cl_text_identifier.constructor" export.result="ti" // correct
A big advantage of this approach is that it allows us to bundle method calls even if new objects are created and then used in subsequent method calls. See the ALV example in section 8 below.
6. Bundling method calls
Multiple method calls can be bundled into a single remote request in the same way as for function calls. Mixing function calls and method calls in a single bundled request is also supported.
For method calls, the bundling option is even more important because function calls typically contain a larger block of code while method calls have finer granularity.
7. Authorization checks
For each method call, GuiXT checks that the user is authorized to execute the given method. The SAP RFC authorization object S_RFC is used for this purpose, using the artificial function name "classname.methodname".
The authorization parameters are:
You may use generic authorizations, e.g. you can allow all methods of class CL_SALV by specifying the value "CL_SALV.*" as RFC_NAME.
8. Example: ALV display as popup
In the following example we use the techniques explained above in order to generate an ALV list as a popup window. We start in transaction BP (Business Partner) in an S/4HANA system.
If the role "Customer" is active and "Sales and Distribution" data are displayed, we add
a button "Show orders", allowing the user to display the sales orders of this customer for the selected sales area:
With the button an InputScript "bp_show_orders.txt" is started; it reads sales order data and displays an ALV popup window:
All standard ALV functions can be used, for example selecting the sort order:
Set V[partner_role] "&F[Display in BP role]"
buttons in role Customer (FLCU01), group box "Sales area"
customer number from business partner number
CreateTable V[customers] kunnr
// Set keys
// determine start date (today minus 12 months)
// create orders table
// read orders
// object variables
// popup position/size
// Create ALV
// allow all standard functions
// Set Title
// Set sort
// Set aggrgations
// Set popup position
// display popup
// run all calls
Scripts as .zip file