Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor


         The draft is a common feature in almost all applications, irrespective of whether it is an SAP or Non-SAP application. A draft is nothing but a temporary version of a business entity that has not yet been explicitly saved as an active version.

         For more details in the context of


         This Blog Post explains Customizing Draft behavior in ABAP RAP Model with a business example and prerequisites are having knowledge of building fiori Applications using the RAP model. I strongly recommend visiting the community page. It is a framework recently introduced to build cloud-ready Fiori applications using ABAP.

         The RAP Model supports Managed, Unmanaged, and Mixed ( Managed with additional save, Managed with unmanaged save)  implementation scenarios. The draft feature can be enabled simply in all the implementation approaches and it is handled by the framework whether it is an unmanaged or a managed scenario. See the documentation

         An application developer does not need to care about how draft data is written to the draft database table. As a default behavior, Framework copies the complete data from active persistence into a draft instance on which the user can continue working on it.

         Of course, there will be some business requirements to tweak this default behavior and adjust the data on the UI for better visibility or control of the features on the UI. So the framework has some extension points to the application and it is the area of interest in this blogpost.

Business Example:

         In a purchase document application, There are three fields Status, Version, and Supplier along with other header information and its items, attachments, etc. The document can be switched into Edit mode in a few statuses like Saved, Rejected, Released/Approved.

         As default behavior, the Active instance is copied into the draft instance with the same data. But the business requirement is


 Case when Status is SAVED

Case when Status is RELEASED/APPROVED

Field - Version Number  Not to be Incremented  Increment with 1
Field - Supplier Changeable Not changeable


Let's see the implementation steps ( Detailed steps can be found in the documentation ) :

  1. Enable the draft feature and provide draft persistence in Behavior Definition using quick-fix.
    unmanaged implementation in class zbp_rk_i_pur_con_ud unique;
    with draft;

    define behavior for ZRK_I_PUR_CON_UD alias PurCon
    draft table zrk_dt_pur_con_u
    lock master
    total etag LoclLastChangedAt
    authorization master ( instance , global )
    etag master LoclLastChangedAt

    field ( numbering : managed, readonly ) ConUuid;

    create ;
    update ;
    delete ;

  2. Make sure the required fields are defined and projected in the entities.
    @AccessControl.authorizationCheck: #CHECK
    @EndUserText.label: 'ZRK_I_PUR_CON_UD'
    define root view entity ZRK_I_PUR_CON_UD as select from zrk_t_pur_con as PurCon

    composition [0..*] of ZRK_I_PUR_CON_I as _PurConItem
    composition [0..*] of zrk_i_pur_con_att as Attachments
    key con_uuid as ConUuid,
    @Consumption.semanticObject: 'PurCon'
    object_id as ObjectId,
    version_no as VersionNo,
    '' as ReleasedAtLeastOnce,
    @Semantics.user.createdBy: true
    created_by as CreatedBy,
    @Semantics.systemDateTime.createdAt: true
    created_at as CreatedAt,
    @Semantics.user.lastChangedBy: true
    last_changed_by as LastChangedBy,
    @Semantics.systemDateTime.lastChangedAt: true
    last_changed_at as LastChangedAt,
    @Semantics.systemDateTime.localInstanceLastChangedAt: true
    local_last_changed_at as LocalLastChangedAt,


  3. Define the draft actions in the behavior definition and project them in behavior projection.
      draft action Resume ;
    draft action Activate ;
    draft action Edit ;
    draft action Discard;
    draft determine action Prepare;​

    use draft;
    use side effects;
    define behavior for ZRK_C_PUR_CON_UD alias PurCon
    use create;
    use update;
    use delete;

    use association _PurConItem { create; with draft; }

    use action Edit;
    use action Activate;
    use action Discard;
    use action Prepare;
    use action Resume;


  4. Mark the version number as a read-only as it is supposed to be generated/managed by the system. Default the value with 1 during create operation.
      field ( readonly ) ObjectId, StatCode , VersionNo;​

  5. Mark the supplier field as Feature: Instance as it is supposed to behave differently by the instance state.
      field ( features : instance ) Supplier  ;​

  6. Enrich the metadata and define the Service definition and Binding, then the Application must be ready for basic testing.

  7. Enhance the Draft Action Edit with Additional Implementation and create a respective method in the Behavior Pool class using quick-fix.
    draft action Edit with additional implementation;​

    IMPORTING keys FOR ACTION PurCon~Edit.

  8. Important step - Implement the extension point with business requirements in the above method 'EDIT'. Notice the important point that active instances will be retrieved by READ ENTITIES and Draft Instance needs to be updated by MODIFY ENTITIES after changing the %is_draft indicator. As per the current business example, Verify the status code and then increment the version number, and set a flag for ReleasedAtLeastOnce so that it can be used later.
      METHOD Edit.

    READ ENTITIES OF zrk_i_pur_con_ud IN LOCAL MODE
    ENTITY PurCon
    FIELDS ( VersionNo )
    RESULT DATA(lt_con).

    IF VALUE #( lt_con[ 1 ]-StatCode OPTIONAL ) EQ 'RLSE' .

    ENTITY PurCon
    UPDATE FIELDS ( VersionNo ReleasedAtLeastOnce )
    WITH VALUE #( FOR <fs_rec_draft> IN lt_con WHERE ( StatCode = 'RLSE' )
    ( %tky = <fs_rec_draft>-%tky <<== Keep the same key
    %is_draft = '01' <<== Adjust to draft instance
    VersionNo = <fs_rec_draft>-VersionNo + 1 <<== Increment version No
    ReleasedAtLeastOnce = abap_true ) ) <<== Set flag to be used later
    REPORTED reported
    FAILED failed
    MAPPED mapped.



  9. Implement the instance feature control method to set the ReadOnly flag to the supplier field based on the above ReleasedAtLeastOnce Flag.
      METHOD get_instance_features.

    READ ENTITIES OF zrk_i_pur_con_ud
    ENTITY PurCon
    FIELDS ( ConUuid ObjectId Buyer StatCode ReleasedAtLeastOnce )
    RESULT DATA(lt_con).

    LOOP AT lt_con ASSIGNING FIELD-SYMBOL(<fs_con>).

    <fs_result> = CORRESPONDING #( <fs_con> ).
    IF <fs_con>-ReleasedAtLeastOnce = abap_true .
    <fs_result>-%field-Supplier = if_abap_behv=>fc-f-read_only .


  10. Customizing the draft feature is completed and ready for the test.

  11. Now the difference in Draft behavior can be observed by taking 2 documents having different statuses.


The scenario to enhance the Draft-EDIT feature using RAP is demonstrated and Similarly, other behaviors in Activating, Discarding the draft instance can be enhanced.

For more information on ABAP Restful Application Programming, Please go through the community page

Labels in this area