ABAP - Keyword Documentation → ABAP RAP Business Objects → ABAP for RAP Business Objects → ABAP for Consuming RAP Business Objects → ABAP EML - Consuming RAP BOs → 

    ROLLBACK ENTITIES

    Syntax


    ROLLBACK ENTITIES.

    Description


    Rolls back all changes of the current RAP transaction. This includes data changes (for example, changes stored in the transactional buffer by calling the cleanup method) and locks. In unmanaged scenarios and in managed scenarios that include an unmanaged or additional save, the RAP BO provider must be implemented to perform the above tasks.

    The statement does not provide any output parameters, for example, response or result parameters. ROLLBACK ENTITIES cannot be called within the RAP BO implementation.

    In case of a natively supported RAP scenario (for example, OData), the ROLLBACK ENTITIES call is performed by RAP. In other cases, for example, manually implemented services or applications, the ROLLBACK ENTITIES call must be done explicitly.

    Hints

    • ABAP EML statements should not be used in loops. Using them can have a performance impact because it can result in multiple single database accesses. There should be only one ABAP EML statement to read the necessary data, and then the data should be modified with an ABAP EML modify request.
    • The rollback request triggers the calling of the cleanup method that clears the transactional buffer.
    • The rollback request (implicitly) triggers the calling of ROLLBACK WORK if the current RAP transaction includes RAP modify operations.

    Further Information


    When implementing RAP operations, ensure that you comply with RAP BO contract.  Follow the implementation guidelines in the development guide for the ABAP RESTful Application Programming Model, section RAP Business Object Contract.

    You can find a selected set of guidelines in here.

    Example


    The following source code demonstrates the effect of the ROLLBACK ENTITIES statements. The instance of the first modify request is saved to the database. The second ABAP EML MODIFY statement is followed by a ROLLBACK ENTITIES statement that clears the instance data from the transactional buffer. Since there is no data in the transactional buffer to be persisted, the following COMMIT ENTITIES statement does not save any data to the database. Consequently, the internal table that is filled by a SELECT statement shows the same content for the second internal table as the first internal table.

    DELETE FROM demo_tab_root. 
     
    MODIFY ENTITY demo_managed_root
      CREATE FIELDS ( key_field data_field1_root
                      data_field2_root )
      WITH VALUE #( ( %cid = 'cid1'
                    key_field = 1
                    data_field1_root = 'aaa'
                    data_field2_root = 'bbb' ) ).
     
    COMMIT ENTITIES.
     
    IF sy-subrc = 0.
      SELECT * FROM demo_tab_root
        INTO TABLE @FINAL(itab1).
    ENDIF.
     
    cl_demo_output=>write( itab1 ).
     
    MODIFY ENTITY demo_managed_root
      CREATE FIELDS ( key_field data_field1_root
                      data_field2_root )
      WITH VALUE #( ( %cid = 'cid2'
                    key_field = 2
                    data_field1_root = 'ccc'
                    data_field2_root = 'ddd' ) ).
     
    ROLLBACK ENTITIES.
     
    COMMIT ENTITIES.
     
    IF sy-subrc = 0.
      SELECT * FROM demo_tab_root
        INTO TABLE @FINAL(itab2).
    ENDIF.
     
    cl_demo_output=>write( itab2 ).
    cl_demo_output=>display( ).

    Executable Example


    The class CL_DEMO_RAP_EML_ROLLBACK_ENTTS demonstrates the effect of the ROLLBACK ENTITIES statement with a managed RAP BO. Two modify operations are executed, the one including the creation of data sets only, the other creating and deleting data sets. Each modify operation is committed separately. The database tables are then emptied and the same operations are carried out again. However, the second modify operation includes the ROLLBACK ENTITIES statement which rolls back the modifications that have not yet been saved from the transactional buffer. Consequently, the output table does not show the changes.