Introduction:
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
Fiori application, check out https://experience.sap.com/fiori-design-web/draft-handling/
ABAP RAP application, check out https://help.sap.com/docs/btp/sap-abap-restful-application-programming-model/draft
Prerequisites:
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
Feature | 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 |
Implementation:
Let's see the implementation steps ( Detailed steps can be found in the documentation ) :
- 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;
strict;
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 ;
}
- 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,
_PurConItem
}
- 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;
projection;
strict;
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;
}
- 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;
- Mark the supplier field as Feature: Instance as it is supposed to behave differently by the instance state.
field ( features : instance ) Supplier ;
- Enrich the metadata and define the Service definition and Binding, then the Application must be ready for basic testing.
- 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;
METHODS Edit FOR MODIFY
IMPORTING keys FOR ACTION PurCon~Edit.
- 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 )
WITH CORRESPONDING #( keys )
RESULT DATA(lt_con).
IF VALUE #( lt_con[ 1 ]-StatCode OPTIONAL ) EQ 'RLSE' .
MODIFY ENTITIES OF zrk_i_pur_con_ud IN LOCAL MODE
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.
ENDIF.
ENDMETHOD.
- 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
IN LOCAL MODE
ENTITY PurCon
FIELDS ( ConUuid ObjectId Buyer StatCode ReleasedAtLeastOnce )
WITH CORRESPONDING #( keys )
RESULT DATA(lt_con).
LOOP AT lt_con ASSIGNING FIELD-SYMBOL(<fs_con>).
APPEND INITIAL LINE TO result ASSIGNING FIELD-SYMBOL(<fs_result>).
<fs_result> = CORRESPONDING #( <fs_con> ).
.......
.......
IF <fs_con>-ReleasedAtLeastOnce = abap_true .
<fs_result>-%field-Supplier = if_abap_behv=>fc-f-read_only .
ENDIF.
ENDLOOP.
- Customizing the draft feature is completed and ready for the test.
- Now the difference in Draft behavior can be observed by taking 2 documents having different statuses.
Conclusion:
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
- SAP Managed Tags:
2 Comments
