[[{“value”:”
Introduction
The Draft capability in SAP RAP enables users to create, modify, and save business data without immediately affecting active records. This feature significantly improves the user experience by allowing work-in-progress changes to be stored and resumed later.
In a standard draft-enabled RAP application, when a user switches to Edit mode, the active data is copied into the draft table and all subsequent operations are performed on the draft instance. However, one important limitation is that access controls and authorization checks cannot be directly applied to a database table.
SAP introduced the Draft Query View . A Draft Query View is a CDS view created on top of the draft table and assigned in the behavior definition using the query addition. When RAP reads draft data, it uses this CDS view instead of directly accessing the draft table. This allows developers to apply DCL rules, authorization checks, and additional filtering logic specifically for draft instances.
what is Query Draft?
A draft query view can be used to define read access limitations to the draft data using data control language(DCL) The DCL access restrictions defined for the CDS view entities selecting from the active database table are not applied to the draft data. A draft query view allows the definition of read access restrictions for draft data.
Implementation steps
Step 1 : Create a Data Base Table
@EndUserText.label : ‘SALES ORDER DATA’
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zte_t_salesdata {
key mandt : abap.clnt not null;
key seller_id : abap.char(5) not null;
name : abap.char(20);
avaliblity : abap_boolean;
created_at : timestampl;
last_changed_at : timestampl;
}
Step 2 : Create root CDS view for table
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: ‘SALES DATA’
@Metadata.ignorePropagatedAnnotations: true
define root view entity ZTE_I_SALESDATA as select from zte_t_salesdata
{
key seller_id as SellerId,
name as Name,
avaliblity as Avaliblity,
created_at as CreatedAt,
last_changed_at as LastChangedAt
}
Step 3: create projection view
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: ‘SALES DATA’
@Metadata.ignorePropagatedAnnotations: true
define root view entity ZTE_C_SALESDATA
provider contract transactional_query as projection on ZTE_I_SALESDATA
{
@UI.facet: [{ id: ‘salesdetails’,
position: 1,
label: ‘SALES DATA’,
type: #IDENTIFICATION_REFERENCE
} ]
@UI.lineItem: [{ position: 1, label : ‘SELLER ID’ }]
@UI.identification: [{ position: 1, label : ‘SELLER ID’ }]
key SellerId,
@UI.lineItem: [{ position: 2, label : ‘SELLER Name’ }]
@UI.identification: [{ position: 2, label : ‘SELLER Name’ }]
Name,
@UI.lineItem: [{ position: 3, label : ‘Avalilabity’ }]
@UI.identification: [{ position: 3, label : ‘Avalilabity’ }]
Avaliblity,
@ui.lineItem: [{ position: 4, label : ‘Created At’ }]
@UI.identification: [{ position: 4, label : ‘Created At’ }]
CreatedAt,
@ui.lineItem: [{ position: 5, label : ‘LastChangedAt’ }]
@UI.identification: [{ position: 5, label : ‘LastChangedAt’ }]
LastChangedAt
}
Step 4 : Create Behavior Definition
- Here create a Draft
- After creating draft table create a interface view top of draft table
- Will declaring the draft table use the QUERY keyword and provide the interface view name of the draft table
Draft Data base Table
@EndUserText.label : ‘Draft table for entity ZTE_I_SALESDATA’
@AbapCatalog.enhancement.category : #EXTENSIBLE_ANY
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zte_sales_d {
key mandt : mandt not null;
key sellerid : abap.char(5) not null;
name : abap.char(20);
avaliblity : abap_boolean;
createdat : timestampl;
lastchangedat : timestampl;
“%admin” : include sych_bdl_draft_admin_inc;
}
Interface view of Draft data base table
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: ‘Draft sales data’
@Metadata.ignorePropagatedAnnotations: true
define view entity ZTE_I_SALESDATA_D as select from zte_sales_d
{
key sellerid as Sellerid,
name as Name,
avaliblity as Avaliblity,
createdat as Createdat,
lastchangedat as Lastchangedat,
draftentitycreationdatetime as Draftentitycreationdatetime,
draftentitylastchangedatetime as Draftentitylastchangedatetime,
draftadministrativedatauuid as Draftadministrativedatauuid,
draftentityoperationcode as Draftentityoperationcode,
hasactiveentity as Hasactiveentity,
draftfieldchanges as Draftfieldchanges
}
Step 5 : Define Projection behavior
projection;
strict ( 2 );
use draft;
define behavior for ZTE_C_SALESDATA //alias <alias_name>
{
use create;
use update;
use delete;
use action Activate;
use action Resume;
use action Discard;
use action Prepare;
use action Edit;
}
Step 6 : Create access control for both interface view(main interface view and draft interface view)
Access control for main Interface view
@EndUserText.label: ‘Sales Data’
@MappingRole: true
define role ZTE_R_SALESDATA {
grant
select
on
ZTE_I_SALESDATA
where
avaliblity = ‘X’;
}
Access control for draft interface view
@EndUserText.label: ‘Sales Data Draft’
@MappingRole: true
define role ZTE_R_SALESDATA_D {
grant
select
on
ZTE_I_SALESDATA_D
where
Avaliblity is initial;
}
Step 7 : Create Service definition and service binding
Service Definition
@EndUserText.label: ‘sales data’
define service Zsd_te_SalesData {
expose ZTE_C_SALESDATA;
}
Service Binding
The Binding Type has to be ODATA V4
Result
If the Field Availability is ‘X’ then the data will be shown as Saved Version and cannot edit the record.
If the Field Availability is Not ‘X’ then the data will be shown as Draft and can edit the record.
Conclusion
Draft Query in SAP RAP allows controlled access to draft data by placing a CDS view over the draft table and assigning it via the query addition in the behavior definition.
Key benefits:
- Apply authorization checks, DCL rules, and custom filters specifically for drafts
- Draft and active entities can follow independent visibility rules
“}]]
#abap