Show TOC

Generating Static ProxiesLocate this document in the navigation structure

Process

Use transaction ACO_PROXY to generate a proxy class. Enter the following:

  • The name of the remote enabled function
  • Select the type of metadata retrieval: RFC or File Upload
    Note In some cases, for example if systems belong to different customers, metadata retrieval is not allowed by the server system owners. In these cases a static proxy can be generated by metadata transferred per XML file.
  • The destination name of the remote system for metadata lookup (only if RFC is selected for metadata retrieval)
  • Select the type of metadata storage: generating a proxy class or saving the data in a file.
  • The name of the new proxy class and the package (only if Class is selected for metadata storage)
Additionally, you can select the following options:
  • The type of exceptions that should be used: Class based exceptions or classic exceptions.
    Note Class based exceptions are not available in all releases, therefore this option is omitted in some releases.
  • Wether bgRFC should be used for metadata retrieval.
  • Whether the proxy should be generated for synchronous or asynchronous call.

    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 the function module does not figure in this list, the proxy would throw an exception.

IF_ACO_PROXY

All proxy classes implement the interface IF_ACO_PROXY, using the package interface SAP_ACO. The interface is empty as it is only used as a marker interface to identify the class as a proxy class. The interface can be used to find all generated proxy classes by using the where used list.
Note If you remove that interface manually, the class can no longer be identified as a generated proxy class.

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.

Note It is not possible to generate proxies for function modules containing parameters named _DEST_, _TASK_, _RESULT_CLASS_ or _RFC_ERROR_ or exceptions named RFC_COMMUNICATION_FAILURE, RFC_SYSTEM_FAILURE, RFC_RESOURCE_FAILURE. See example report: SAP_ACO_EXAMPLE_PROXY_ASYNCALL.

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.