
Use transaction ACO_PROXY to generate a proxy class. Enter the following:
In case of an asynchronous call, you can specify whether the results should be retrieved and whether the task should be kept or not. See the online documentation of asynchronous RFC for more information.
Wether the Function Module should be generated using a variable name.
In this case you should also specify a class that checks the transferred function module name before it is called dynamically .
This class must implement the interface IF_ACO_WHITE_LIST_PROVIDER. The method GET_WHITE_LIST gets the destination, the function module name used and an internal info (in String format) that can be specified on generation and should return a list with valid function module names.
IF_ACO_PROXY
The generated proxy will contain a method that has the same name like the corresponding remote function module. Additionally all needed types are defined as public types in the generated class. The method contains the same parameters as the remote function (in asynchronous mode only importing, changing and tables parameters, but no exporting parameters).
Table parameters are passed as changing parameters, since classes do not support tables parameters. All parameters refer to types declared in the class. The class is completely self-contained. An additional parameter _DEST_ is generated to pass the destination for use at runtime.
If you specify classic exceptions in the generation, the additional exceptions RFC_COMMUNICATION_FAILURE, RFC_SYSTEM_FAILURE, RFC_RESOURCE_FAILURE, and the additional parameter _RFC_ERROR_ are automatically created. These exceptions are raised whenever the remote function call raises COMMUNICATION_FAILURE, SYSTEM_FAILURE, or RESOURCE_FAILURE. The character parameter __RFC_ERROR__ contains more detailed information from the runtime.
If you specify synchronous call, another parameter named _TASK_ is created. When calling the proxy, you need to specify a task name to perform the asynchronous task (see task in documentation of asynchronous RFC).
In case you specified retrieving results, the proxy class will contain another additional parameter: _RESULT_CLASS_ and an additional method RECEIVE_RESULT. This method can be called, when the asynchronous call is finished to retrieve the results. Therefore RECEIVE_RESULT contains changing, exporting and table types of the remote function.
In parameter _RESULT_CLASS_, you need to pass a subclass of the abstract class CL_ACO_PROXY_RECEIVE_RESULT. This class also defines an attribute PROXY and a method RECEIVE_RESULT with just one parameter P_TASK. This method is called at the end of the asynchronous task. The attribute proxy is, at that time, filled by the actual instance of the proxy class.
Typically, the implementation of RECEIVE_RESULT will start like this:
data: myproxy type ref to <generated proxyclass>.
myproxy ?= me->proxy.
call method myproxy->receive_result
exporting …
Then, the retrieved result can be transferred somehow to your application, for example, by specifying additional attributes and methods or by calling other classes.
As an alternative to the transaction ACO_PROXY, you can generate the proxy in your program by using the following code:
data: callback type ref to <callback class>,
destination type ref to if_aco_destination,
repository type ref to if_aco_repository.
create object callback. "or call factory
try.
destination = cl_aco_destination_manager=>get_destination(
destination_name = <destination> )..
repository = destination->get_repository( ).
repository->create_static_proxy(
function_name = <function_name>
proxy_name = <proxy_name>
devclass = <devclass>
opt_param_callback = <opt_param_callback>
classic_exceptions = <classic_exceptions>
asynchronous_task = <asynchronous_task>
receive_result = <receive_result>
keep_task = <keep_task>
).
Catch CX_ACO_EXCEPTION.
" error handling
endtry.
The callback class is designed to choose the optional parameters that should be included in the proxy class.
Use any class that implements the interface IF_ACO_OPT_PARAM_CALLBACK.
Implement method MODIFY_OPT_PARAMS. The method has just one changing parameter OPT_PARAMETERS. The parameter receives all optional parameters in a changing table.
If you like to exclude parameters from the proxy generation, simply remove them from the table parameter MODIFY_OPT_PARAMS.