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

FOR MODIFY

Other versions: ~~7.31~~ | ~~7.40~~ | 7.54

Syntax


METHODS method_name FOR MODIFY 
  [IMPORTING] 

    create_import_parameter FOR CREATE entity_name 
    create_import_parameter FOR CREATE entity_name\association 

    update_import_parameter FOR UPDATE entity_name 
    delete_import_parameter FOR DELETE entity_name 

    action_import_parameter FOR ACTION entity_name~action 
          [RESULT action_export_parameter] 

   ... 
   [CHANGING  failed   TYPE DATA 

              mapped   TYPE DATA 

              reported TYPE DATA].

Effect

The method MODIFY implements the handler that makes changes to the entities in the context of the ABAP RESTful programming model. This method is called if the application is processing a change request containing at least one of the change operations (CREATE, UPDATE, DELETE, or ACTION) specified in the behavior definition. The command ... parameter IS [NOT] INITIAL can be used to determine which operations are actually used.

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

No rules apply to the order in which individual operations are processed within a MODIFY method. The application processes all individual passed operations in an appropriate order, for example create operations before update operations.

The method name method_name can be specified freely. Using this generalization, it is possible to accommodate multiple MODIFY methods in a single handler class. For example, each action can be defined as a method in the same 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.

Input Parameters

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

The row type of the input parameters for the corresponding operations contains the following (the associated parameters are flagged with "x"):

Operation	ID	%CID	%CID_REF	%KEY	%PID	%CONTROL	%DATA	%PARAM
CREATE	-	x	-	-	-	x	-	-
UPDATE	-	-	x	x	x	x	x	-
DELETE	x	-	x	-	x	-	-	-
ACTION	x	-	x	-	x	-	-	x

Output Parameters

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

For an action with the addition RESULT, a named output parameter must be filled. Other operations do not necessarily have visible results. If they do, the results are written implicitly to three return structures (failed, mapped, and reported for errors, mappings, or messages). They can, however, be declared explicitly as CHANGING parameters in the method signature using the generic type DATA:

CHANGING failed   TYPE DATA
         mapped   TYPE DATA
         reported TYPE DATA

The parameters failed, mapped and reported don’t have fixed data types and are assigned with derived types from the behavior definition instead.

Remarks

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

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

The parameters can also be declared explicitly as REFERENCE (...).

A declaration as VALUE (...) is not allowed. This means that the input parameters in a MODIFY method cannot be changed.

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 definitions and implementations

of the standard operations create, update, and delete (for creating, updating, and deleting instances of the entity Travel) and

the application-specific action set_status_booked (for setting the trip status to booked).

In the example, each of the operations and the action are implemented in the methods modify_create, modify_update, modify_delete, and set_status. The basic structure of the implementation of the methods is similar. For example, the implementation of the method modify_create includes

a loop for all new instances of the entity Travel to be created,

calling the function module of the legacy business logic /DMO/FLIGHT_TRAVEL_CREATE for creating new Travel instances, and

message handling for processing instance-specific messages if an error occurs (msgty = 'E' for an error, msgty = 'A' for an abortion).

The second step can generate failed keys (ls_travel_create-%cid) and messages (lt_messages). Failed keys are saved in the table failed while all instance-specific messages are saved in the table reported. If successful (lt_messages IS INITIAL), the content ID (%CID) and the new key travel_id are written to the table mapped.

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.

  PRIVATE SECTION.
    METHODS modify_create FOR MODIFY
      IMPORTING
        it_travel_create    FOR CREATE travel.

    METHODS modify_update FOR MODIFY
      IMPORTING
        it_travel_update    FOR UPDATE travel.

    METHODS modify_delete FOR MODIFY
      IMPORTING
        it_travel_delete    FOR DELETE travel.

    METHODS set_status    FOR MODIFY
      IMPORTING
        it_travel_set_status_booked
                            FOR ACTION travel~set_status_booked
      RESULT
        et_travel_set_status_booked.

ENDCLASS.

CLASS lcl_travel_handler IMPLEMENTATION.

  METHOD modify_create.
    DATA ls_travel_out TYPE /dmo/travel.
    DATA lt_messages   TYPE /dmo/if_flight_legacy=>tt_message.
    LOOP AT it_travel_create INTO DATA(ls_travel_create).
      CALL FUNCTION '/DMO/FLIGHT_TRAVEL_CREATE'
        EXPORTING
          is_travel   = CORRESPONDING
            /dmo/if_flight_legacy=>ts_travel_in( ls_travel_create )
        IMPORTING
          es_travel   = ls_travel_out
          et_messages = lt_messages.
      IF lt_messages IS NOT INITIAL.
        zcl_messages=>handle_messages(
          EXPORTING
            iv_cid      = ls_travel_create-%cid
            it_messages = lt_messages
          CHANGING
            failed   = failed-travel
            reported = reported-travel ).
        CONTINUE.
      ENDIF.
      INSERT VALUE #( %cid    = ls_travel_create-%cid
                    travel_id = ls_travel_out-travel_id )
        INTO TABLE mapped-travel.
    ENDLOOP.
  ENDMETHOD.

  METHOD modify_update.
    DATA ls_travel_out TYPE /dmo/travel.
    DATA lt_messages   TYPE /dmo/if_flight_legacy=>tt_message.
    LOOP AT it_travel_update INTO DATA(ls_travel_update).
      ls_travel_update-travel_id = COND #(
        WHEN ls_travel_update-travel_id IS INITIAL
        OR ls_travel_update-travel_id = ''
        THEN mapped-travel[ %cid = ls_travel_update-%cid_ref ]-travel_id
        ELSE ls_travel_update-travel_id ).
      DATA(ls_travelx) = zcl_messages=>map_travel_control(
        is_travel = ls_travel_update ).
      CALL FUNCTION '/DMO/FLIGHT_TRAVEL_UPDATE'
        EXPORTING
          is_travel   = CORRESPONDING
            /dmo/if_flight_legacy=>ts_travel_in( ls_travel_update )
          is_travelx  = ls_travelx
        IMPORTING
          et_messages = lt_messages.
      LOOP AT lt_messages INTO DATA(ls_message)
          WHERE msgty = 'E' OR msgty = 'A'.
        zcl_messages=>handle_messages(
          EXPORTING
            iv_cid       = ls_travel_update-%cid_ref
            iv_travel_id = ls_travel_update-travel_id
            it_messages  = lt_messages
          CHANGING
            failed   = failed-travel
            reported = reported-travel ).
      ENDLOOP.
    ENDLOOP.
  ENDMETHOD.

  METHOD modify_delete.
    DATA: lt_messages   TYPE /dmo/if_flight_legacy=>tt_message,
          ls_travel_out TYPE /dmo/travel.
    LOOP AT it_travel_delete INTO DATA(ls_travel_delete).
      ls_travel_delete-travel_id = COND #(
        WHEN ls_travel_delete-travel_id IS INITIAL
        OR ls_travel_delete-travel_id = ''
        THEN mapped-travel[ %cid = ls_travel_delete-%cid_ref ]-travel_id
        ELSE ls_travel_delete-travel_id ).
      CALL FUNCTION '/DMO/FLIGHT_TRAVEL_DELETE'
        EXPORTING
          iv_travel_id = ls_travel_delete-travel_id
        IMPORTING
          et_messages  = lt_messages.
      zcl_messages=>handle_messages(
        EXPORTING
          iv_cid       = ls_travel_delete-%cid_ref
          iv_travel_id = ls_travel_delete-travel_id
          it_messages  = lt_messages
        CHANGING
          failed       = failed-travel
          reported     = reported-travel ).
    ENDLOOP.
  ENDMETHOD.

  METHOD set_status.
    DATA lt_messages TYPE /dmo/if_flight_legacy=>tt_message.
    CLEAR et_travel_set_status_booked.
    LOOP AT it_travel_set_status_booked
        ASSIGNING FIELD-SYMBOL(<fs_travel_set_status_booked>).
      DATA(lv_travel_id) =
        <fs_travel_set_status_booked>-travel_id.
      IF lv_travel_id IS INITIAL OR lv_travel_id = ''.
        lv_travel_id = mapped-travel[
          %cid = <fs_travel_set_status_booked>-%cid_ref
                                    ]-travel_id.
      ENDIF.
      CALL FUNCTION '/DMO/FLIGHT_TRAVEL_SET_BOOKING'
        EXPORTING
          iv_travel_id = lv_travel_id
        IMPORTING
          et_messages  = lt_messages.
      zcl_messages=>handle_messages(
        EXPORTING
          iv_cid       = <fs_travel_set_status_booked>-%cid_ref
          iv_travel_id = lv_travel_id
          it_messages  = lt_messages
        CHANGING
          failed       = failed-travel
          reported     = reported-travel ).
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.