Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  ABAP RESTful Programming Model →  Behavior Implementations →  Handler Class 


Other versions: 7.31 | 7.40 | 7.54


METHODS method_name FOR READ 
     read_import_parameter   FOR READ entity_name
       [RESULT read_export_parameter]
     read_import_param_assoc FOR READ entity_name_assoc
        FULL   read_export_param_full
        RESULT read_export_param_assoc
        LINK   read_export_param_link
  [image TYPE if_abap_behv=>t_image]
            reported TYPE DATA].


The READ method implements the handler that processes read requests for the entities in the context of the ABAP RESTful programming model. The method is used to return data from the application buffer. If the buffer is empty, the data must be read from the database.

The READ method can be called to support handling of an ETag. A change operation (such as update) is triggered by the if match condition. First the LOCK method is called. If the LOCK method was successful, the READ method is triggered to request the current ETag value. The structure %CONTROL requests the ID fields and the ETag attributes. The data is then checked using the if match condition. If the check is passed, the change method is called.

Like MODIFY methods, the READmethod is mass-enabled and bundle-enabled. This means that it can handle mass requests and implement multiple operations. Multiple operations in a READ method, however, are not permitted.

The method name method_name is arbitrary. Using this generalization, it is possible to accommodate multiple READ methods in a single handler class. This enables the behavior implementation of a business object without introducing a corresponding number of handler classes.

entity_name refers to the name of the entity or the alias, if one is defined in the behavior definition.

Just like the direct operation read, the operation read-by-association uses a table with instance keys of the source entity as input parameter read_import_param_assoc. The output is as follows:

  • FULL
    Boolean parameter indicating whether the consumer is making a query based only on the links or whether full results are queried.
    A table with the full row type of the target entity.
  • LINK
    A table in which source keys and target keys are set in relationship with each other.

Input Parameters

The name of the input parameter (for example, read_import_parameter) can be specified freely.

The row structure of the input parameter contains the following components:

  • %PID
  • ID fields

Furthermore, the implicit input parameter image can be declared explicitly as an optional parameter:

  [IMPORTING] image TYPE if_abap_behv=>t_image

The values of the parameter image are as follows:

  • transactional
    This is the parameter's default value. The state of the entities is queried from the transactional buffer.
  • before
    The state of the entities is queried from the database.

Output Parameters

The name of the output parameter (for example, read_export_parameter) can be specified freely.

The output parameter read_export_parameter, which can be declared explicitly, has the successfully read data as its output. Its row structure contains the following components:

  • %PID
  • All fields of the entity.

The output parameters failed and reported for errors or messages are added implicitly (automatically). They can, however, be declared explicitly as CHANGING parameters in the method signature using the generic type DATA:

         reported TYPE DATA

The parameters failed and reported don’t have fixed data types and are assigned with derived types from the behavior definition instead. The parameter mapped is part of the method signature, but it is not used in the method.


The control structure %CONTROL shows which elements are requested by the consumer. It may, however, be a good idea to return all elements and not just the requested elements.


  • The old syntax METHODS read FOR BEHAVIOR ... is also valid but is not recommended.

  • The keyword IMPORTING is not mandatory and can be specified in front of the input parameter.


In the following example, the data from the ABAP flight data reference scenario (or flight data scenario for short) is used. It represents a legacy business logic that can be used to create and edit flight bookings. The root entity Travel represents the business object for managing flight trips. The underlying data model and the behavior of the root entity Travel are described in ABAP BDL - Example.

The following example shows the definition and the implementation of the READ method read_travel for processing read requests for the entity Travel. The implementation of the method includes

  • a loop for all instances of the entity Travel to be read,
  • calling the function module of the legacy business logic /DMO/FLIGHT_TRAVEL_READ for reading Travel instances, and
  • message handling for processing instance-specific messages if an error occurs. For the sake of readability, the methods for handling the messages are implemented in the separate class zcl_messages. The class zcl_messages is described in Example - Handling of Messages.
CLASS lcl_travel_handler DEFINITION
    INHERITING FROM cl_abap_behavior_handler.

    METHODS read_travel FOR READ
        it_travel_read FOR READ travel
      RESULT et_travel.

CLASS lcl_travel_handler IMPLEMENTATION.

  METHOD read_travel.
    DATA: lt_messages   TYPE /dmo/if_flight_legacy=>tt_message,
          ls_travel_out TYPE /dmo/travel.
    LOOP AT it_travel_read INTO DATA(ls_travel_read).
          iv_travel_id = ls_travel_read-travel_id
          es_travel    = ls_travel_out
          et_messages  = lt_messages.
      IF lt_messages IS NOT INITIAL.
            iv_travel_id = ls_travel_read-travel_id
            it_messages  = lt_messages
            failed       = failed-travel
            reported     = reported-travel
      INSERT CORRESPONDING #( ls_travel_out ) INTO TABLE et_travel.