Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Data Interfaces and Communication Interfaces →  ABAP and XML →  Transformations for XML →  ST - Simple Transformations →  ST - Access to ABAP Objects from ST 

ST - tt:call-method, Call Static Methods

Other versions: 7.31 | 7.40 | 7.54

Syntax


<tt:call-method class="class" [s-|d-]name="meth" 
    
                         [writer = "writer_para"] 

                 
            [reader = "reader_para"] 
  [<tt:with-parameter [s-|d-]name="para1" 

                      [ref="node1"|val="val1"|var="var1"] /> 

   <tt:with-parameter [s-|d-]name="para2" 
       
              [ref="node2"|val="val2"|var="var2"] /> 
   ...] 
</tt:call-method>

Effect

Using this variant of the statement tt:call-method, a static method of a global ABAP Objects class can be called in an ST program as follows: class can be used to specify a class from the class library and meth can be used to specify a visible method of this class. This is not case-sensitive. The method is called for both serializations and deserializations when name is declared; it is called for serializations only when s-name is declared and for deserializations only when d-name is declared.

The interface parameters para1, para2, … of the called method can or must be bound to actual parameters, using the ST command tt:with-parameter. The attribute name specifies the name of a formal parameter. An actual parameter is bound to this attribute only in serializations (if s-name is specified) and only in deserializations (if d-name is specified). In certain cases, this allows a single method to be used for both directions. As actual parameters, ref can be used to specify data roots, var to specify variables or parameters, and val to specify values. Depending on the kind of formal parameter, the values of the specified actual parameters are either passed in the call or used when the called method ends.

When actual parameters are used, read-only access to data roots is possible only in serializations, which is why they can only be passed to input parameters of the method. In the reverse case (deserializations), only write access to data roots is possible, which is why they can be used only by output parameters or return codes.

The type of an actual parameter must match the typing of the interface parameter. The type of a data root, which can itself be typed in the statement tt:root, is determined by the type of the bound ABAP data object. Parameters and variables do not have a static type, unless the addition ref-type of the statements tt:parameter or tt:variable defines them as reference variables. Data reference variables defined in this way can be bound to interface parameters of the same type.

When a method is called, control passes from the ST processor to the ABAP processor of the ABAP runtime environment. There are no restrictions on which statements can be executed in the method. If ENDMETHOD or RETURN is used to exit a method correctly, control passes to the ST processor again and the ST program resumes after tt:call-method. Otherwise, the control does not pass back to the ST program:

  • If a statement such as LEAVE PROGRAM, SUBMIT without the addition AND RETURN, or LEAVE TO TRANSACTION is used to exit the method, the program responds as if the method were called from an ABAP program; that is, the current internal mode is deleted, together with the ST program.
  • If the method is terminated by a class-based exception, and the exception is propagated from the method, the statement CALL TRANSFORMATION is terminated with the handleable exception CX_ST_CALL_METHOD_ERROR. The EXCEPTION_NAME attribute of the exception object is then given the name of the original exception.
  • Non-class-based exceptions cannot be handled. A method terminated using a non-class-based exception always causes a runtime error.

If ABAP data objects are modified in the called method, and these data objects are bound to data roots of the calling ST program, these modifications take effect immediately in the ST program. The following restriction applies: If a method is called within a tt:loop loop, serialization within the method (and within further nested tt:loop loops) only permits read-only access to the current internal table or its components. Deserialization within the method does not allow any access. Otherwise, a runtime error occurs.

Using the optional attributes writer and reader, the input parameters writer_para or reader_para of the called method can be specified. These parameters must have the references types IF_SXML_WRITER or IF_SXML_READER. If s-name is specified, only writer can be specified. If d-name is specified, only reader can be specified. If name is specified, both attributes can be specified. writer is used for serialization and reader is used for deserialization. These attributes can be used to pass a reference to the XML writer or the XML reader (created by CALL TRANSFORMATION) to called method. In the method, the relevant interface can be used to access the reader or writer.


Note

If variables or parameters are bound to the interface parameters of called methods, note that these variables or parameters can be serialized or deserialized only if they contain elementary values.


Example

The following transformation exists as DEMO_ST_WITH_METHOD_CALL in AS ABAP. In a serialization in a tt:loop loop, it uses the data root SCARR_TAB to call the static method GET_FLIGHTS of the global class CL_DEMO_CALL_FROM_ST. This passes the component carrid of the internal table scarr_tab to the input parameter of the method.

<tt:transform
  xmlns:tt="http://www.sap.com/transformation-templates">
  <tt:root name="SCARR_TAB"/>
  <tt:root name="SPFLI_TAB"/>
  <tt:template>
    <Flights>
      <tt:loop ref=".SCARR_TAB">
        <Flights>
          <tt:attribute name="Carrier" value-ref="CARRNAME"/>
          <tt:call-method class="CL_DEMO_CALL_FROM_ST"
                          s-name="GET_FLIGHTS">
            <tt:with-parameter name="CARRID" ref="carrid"/>
          </tt:call-method>
          <tt:loop ref=".SPFLI_TAB">
            <Connection>
              <tt:attribute name="ID" value-ref="CONNID"/>
              <From>
                <tt:value ref="CITYFROM"/>
              </From>
              <To>
                <tt:value ref="CITYTO"/>
              </To>
            </Connection>
          </tt:loop>
        </Flights>
      </tt:loop>
    </Flights>
  </tt:template>
</tt:transform>

The simple transformation can be called in a different method MAIN of the same class DEMO_ST_WITH_METHOD_CALL as follows:

METHOD main.
  DATA:  scarr_tab TYPE SORTED TABLE OF scarr
                    WITH UNIQUE KEY carrid,
         xml_string TYPE string,
         exc        TYPE REF TO cx_st_call_method_error.
  SELECT *
         FROM scarr
         INTO TABLE @scarr_tab.
  IF sy-subrc <> 0.
    RETURN.
  ENDIF.
  TRY.
      CALL TRANSFORMATION demo_st_with_method_call
        SOURCE scarr_tab = scarr_tab
               spfli_tab = spfli_tab
        RESULT XML xml_string.
    CATCH cx_st_call_method_error INTO exc.
      MESSAGE exc TYPE 'I' DISPLAY LIKE 'E'.
      RETURN.
  ENDTRY.
  cl_abap_browser=>show_xml( EXPORTING xml_string = xml_string ).
ENDMETHOD.

The internal tables scarr_tab and spfli_tab are both static attributes of the class. scarr_tab is filled and passed to the transformation data root with the same name; spfli_tab, however, remains empty and is filled in a different way (in the method GET_SPFLI called from the simple transformation) in each loop, in accordance with the parameter carrid.

The method MAIN is bound to the transaction code DEMO_ST_METHOD_CALL and produces the following result:

<FlightList>
  <Flights Carrier="American Airlines">
    <Connection ID="0017">
      <From>NEW YORK</From>
      <To>SAN FRANCISCO</To>
    </Connection>
    <Connection ID="0064">
      <From>SAN FRANCISCO</From>
      <To>NEW YORK</To>
    </Connection>
    <Connection ID="0555">
      <From>ROME</From>
      <To>FRANKFURT</To>
    </Connection>
    ...
  </Flights>
  <Flights Carrier="Air Berlin">
    ...
  </Flights>
</FlightList>

The program above uses the binding of the attribute spfli_tab to the simple transformation, and write access to this attribute in the called method, to enable write access to data nodes in serializations within the ST program.