ABAP Keyword Documentation → ABAP − Reference → ABAP RESTful Programming Model → Behavior Implementations → Handler Class
FOR READ
Other versions:
7.31 | 7.40 | 7.54
Syntax
METHODS method_name FOR READ
[IMPORTING]
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]
...
[CHANGING failed TYPE DATA
reported TYPE DATA].
Effect
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.
- RESULT
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
- %CONTROL.
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.
Tip
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.
Remarks
- 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.
Example
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.
INHERITING FROM cl_abap_behavior_handler.
PRIVATE SECTION.
METHODS read_travel FOR READ
IMPORTING
it_travel_read FOR READ travel
RESULT et_travel.
ENDCLASS.
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).
CALL FUNCTION '/DMO/FLIGHT_TRAVEL_READ'
EXPORTING
iv_travel_id = ls_travel_read-travel_id
IMPORTING
es_travel = ls_travel_out
et_messages = lt_messages.
IF lt_messages IS NOT INITIAL.
zcl_messages=>handle_messages(
EXPORTING
iv_travel_id = ls_travel_read-travel_id
it_messages = lt_messages
CHANGING
failed = failed-travel
reported = reported-travel
).
CONTINUE.
ENDIF.
INSERT CORRESPONDING #( ls_travel_out ) INTO TABLE et_travel.
ENDLOOP.
ENDMETHOD.
ENDCLASS.