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 LOCK 
        lock_import_parameter FOR LOCK entity_name.
    [CHANGING failed   TYPE DATA
              reported TYPE DATA].


The LOCK implements the handler that locks entities. However, the lock properties lock master or lock dependent must be specified in the behavior definition of a business object. The method lock is called automatically before a change operation (for example, update).

The method name method_name is arbitrary. Using this generalization, it is possible to accommodate multiple LOCK methods in a single handler class.

entity_name refers to the name of the entity or the alias, if it exists, as defined in the behavior definition.

Input Parameters

The following points apply to the input parameter lock_import_parameter:

  • The name of the input parameter can be freely defined.
  • The row type of the input parameter provides the ID fields. This structure contains the fields of the entity that are specified as keys.
  • The fields %CID, %CID_REF, and %PID generated by ABAP Compiler are not required in the context of locks, since locks are only relevant for instances saved in the database.

Output Parameters

The output parameters failed and reported for errors or messages are added 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 old syntax METHODS lock FOR BEHAVIOR ... is also valid but is no longer 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 implementation of the LOCK method lock_travel. The implementation of the method includes

  • a loop for all instances of the entity Travel to be locked,
  • calling the function module of the legacy business logic ENQUEUE_/DMO/ETRAVEL, and
  • message handling for processing instance-specific messages. 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 lock_travel FOR LOCK
        it_travel_key FOR LOCK travel.

CLASS lcl_travel_handler IMPLEMENTATION.

  METHOD lock_travel.
    LOOP AT it_travel_key ASSIGNING FIELD-SYMBOL(<fs_travel>).
          travel_id      = <fs_travel>-travel_id
          foreign_lock   = 1
          system_failure = 2
          OTHERS         = 3.
      ASSERT sy-subrc < 2.
      IF sy-subrc = 1.
        INSERT zcl_messages=>map_travel_message(
           iv_travel_id = <fs_travel>-travel_id
           is_message   = VALUE #( msgid = '/DMO/CM_FLIGHT_LEGAC'
                                   msgty = 'E'
                                   msgno = '032'
                                   msgv1 = <fs_travel>-travel_id
                                   msgv2 = sy-msgv1 ) )
          INTO TABLE reported-travel.
        APPEND VALUE #( travel_id = <fs_travel>-travel_id )
               TO failed-travel.