Draft actions in the ABAP RESTful Application Programming (RAP) model are used to handle temporary versions of business objects before they are saved as active versions.
Here are some key points about draft actions in RAP:
Draft Actions: These include Edit, Activate, Discard, and Resume. They allow data manipulation on the RAP draft table.
Behavior Definition: Draft actions must be specified in the behavior definition of the business object. This ensures that the draft handling is enabled.
Implementation: While RAP provides default implementations for these actions, you can customize them as needed. For example, you might want to control which fields can be edited or how data is validated
Draft Action Edit
The draft action EDIT copies an active instance to the draft database table. Feature and authorization control is available for the EDIT, which you can optionally define to restrict the usage of the action.
Draft Action Activate
The draft action ACTIVATE is the inverse action to EDIT. It invokes the PREPARE and a modify call containing all the changes for the active instance in case of an edit-draft, or a CREATE in case of a new-draft. Once the active instance is successfully created, the draft instance is discarded.
In contrast to the draft action Edit, the Activate does not allow feature or authorization control. Authorization is not available as the Activate only transfers the state of the draft buffer to the active buffer. Authorization is controlled when the active instance is saved to the database.
The draft action activate is also available in an optimized variant which can improve the performance compared to the variant without optimization.
Draft Action Discard
The draft action DISCARD deletes the draft instance from the draft database table. No feature or authorization control can be implemented.
Draft Determine Action Prepare
The draft determine action PREPARE executes the determinations and validations that are specified for it in the behavior definition. The PREPARE enables validating draft data before the transition to active data.
In the behavior definition, you must specify which determinations and validations are called during the prepare action. Only determinations and validations that are defined and implemented for the BO can be used.
Note
For performance reasons, determinations and validations are not executed during the draft determine action Prepare, if these determinations and validations have already been executed during a previous determine action that has been executed on the instance in the same transaction.
This performance optimization is not applied in the following cases:
A modification performed after the first determine action triggers a determination/validation.
A validation in the first determine action reports a failed key.
A determination/validation has been assigned using the addition always.
In order to ensure data consistency, make sure that your determinations and validations follow the respective modelling guidelines described in Determination and Validation Modelling.
Draft Action Resume
The draft action RESUME is executed when a user continues to work on a draft instance whose exclusive lock for the active data has already expired. It recreates the lock for the corresponding instance on the active database table. On a Fiori Elements UI, it is invoked when reopening and changing a draft instance whose exclusive lock is expired.
In case of a new draft, the same feature and authorization control is executed as defined for a CREATE. In case of an edit-draft, the same feature and authorization control is executed like in an Edit.
It is sequence of triggering when edit is done in Draft.
In the Behavior define the draft actions
managed implementation in class ZBP_R_NP_DT_PARTNER unique;
strict ( 2 );
with draft;
define behavior for ZR_NP_DT_PARTNER alias ZrNpDtPartner
persistent table znp_dt_partner
draft table znp_dt_partner_d
etag master LastChangedAt
lock master total etag LastChangedAt
authorization master ( global )
{
field ( mandatory : create )
Partner;
field ( readonly )
CreatedBy,
CreatedAt,
LastChangedBy,
LastChangedAt;
field ( readonly : update )
Partner;
create;
update;
delete;
validation city on save { field City; create; }
validation currency on save { field PaymentCurrency; create; update; }
draft action Activate optimized with additional implementation;
draft action Discard with additional implementation;
draft action Edit with additional implementation;
draft action Resume with additional implementation;
draft determine action Prepare
{
validation City;
validation currency;
}
mapping for znp_dt_partner
{
Partner = partner;
Name = name;
Street = street;
City = city;
Country = country;
PaymentCurrency = payment_currency;
CreatedBy = created_by;
CreatedAt = created_at;
LastChangedBy = last_changed_by;
LastChangedAt = last_changed_at;
}
}
Projection view Behavior Definition.
projection implementation in class ZBP_C_NP_DT_PARTNER unique;
strict ( 2 );
use draft;
define behavior for ZC_NP_DT_PARTNER alias ZcNpDtPartner
use etag
{
use create;
use update;
use delete;
use action Edit;
use action Activate;
use action Discard;
use action Resume;
use action Prepare;
}
In the draft table the field value will be null hence it is not valid.
If we provide the value and save it will be updated to active instance and that record will be discard from the draft.
Once we add the valid value it will saved to active instance and removed from Draft.
Database table.
Draft table.
Draft actions in the ABAP RESTful Application Programming (RAP) model are used to handle temporary versions of business objects before they are saved as active versions.Here are some key points about draft actions in RAP:Draft Actions: These include Edit, Activate, Discard, and Resume. They allow data manipulation on the RAP draft table.Behavior Definition: Draft actions must be specified in the behavior definition of the business object. This ensures that the draft handling is enabled.Implementation: While RAP provides default implementations for these actions, you can customize them as needed. For example, you might want to control which fields can be edited or how data is validatedDraft Action EditThe draft action EDIT copies an active instance to the draft database table. Feature and authorization control is available for the EDIT, which you can optionally define to restrict the usage of the action. Draft Action ActivateThe draft action ACTIVATE is the inverse action to EDIT. It invokes the PREPARE and a modify call containing all the changes for the active instance in case of an edit-draft, or a CREATE in case of a new-draft. Once the active instance is successfully created, the draft instance is discarded.In contrast to the draft action Edit, the Activate does not allow feature or authorization control. Authorization is not available as the Activate only transfers the state of the draft buffer to the active buffer. Authorization is controlled when the active instance is saved to the database. The draft action activate is also available in an optimized variant which can improve the performance compared to the variant without optimization. Draft Action DiscardThe draft action DISCARD deletes the draft instance from the draft database table. No feature or authorization control can be implemented. Draft Determine Action PrepareThe draft determine action PREPARE executes the determinations and validations that are specified for it in the behavior definition. The PREPARE enables validating draft data before the transition to active data.In the behavior definition, you must specify which determinations and validations are called during the prepare action. Only determinations and validations that are defined and implemented for the BO can be used.NoteFor performance reasons, determinations and validations are not executed during the draft determine action Prepare, if these determinations and validations have already been executed during a previous determine action that has been executed on the instance in the same transaction.This performance optimization is not applied in the following cases:A modification performed after the first determine action triggers a determination/validation.A validation in the first determine action reports a failed key.A determination/validation has been assigned using the addition always.In order to ensure data consistency, make sure that your determinations and validations follow the respective modelling guidelines described in Determination and Validation Modelling. Draft Action ResumeThe draft action RESUME is executed when a user continues to work on a draft instance whose exclusive lock for the active data has already expired. It recreates the lock for the corresponding instance on the active database table. On a Fiori Elements UI, it is invoked when reopening and changing a draft instance whose exclusive lock is expired.In case of a new draft, the same feature and authorization control is executed as defined for a CREATE. In case of an edit-draft, the same feature and authorization control is executed like in an Edit.It is sequence of triggering when edit is done in Draft. In the Behavior define the draft actions managed implementation in class ZBP_R_NP_DT_PARTNER unique;
strict ( 2 );
with draft;
define behavior for ZR_NP_DT_PARTNER alias ZrNpDtPartner
persistent table znp_dt_partner
draft table znp_dt_partner_d
etag master LastChangedAt
lock master total etag LastChangedAt
authorization master ( global )
{
field ( mandatory : create )
Partner;
field ( readonly )
CreatedBy,
CreatedAt,
LastChangedBy,
LastChangedAt;
field ( readonly : update )
Partner;
create;
update;
delete;
validation city on save { field City; create; }
validation currency on save { field PaymentCurrency; create; update; }
draft action Activate optimized with additional implementation;
draft action Discard with additional implementation;
draft action Edit with additional implementation;
draft action Resume with additional implementation;
draft determine action Prepare
{
validation City;
validation currency;
}
mapping for znp_dt_partner
{
Partner = partner;
Name = name;
Street = street;
City = city;
Country = country;
PaymentCurrency = payment_currency;
CreatedBy = created_by;
CreatedAt = created_at;
LastChangedBy = last_changed_by;
LastChangedAt = last_changed_at;
}
} Projection view Behavior Definition. projection implementation in class ZBP_C_NP_DT_PARTNER unique;
strict ( 2 );
use draft;
define behavior for ZC_NP_DT_PARTNER alias ZcNpDtPartner
use etag
{
use create;
use update;
use delete;
use action Edit;
use action Activate;
use action Discard;
use action Resume;
use action Prepare;
} In the draft table the field value will be null hence it is not valid. If we provide the value and save it will be updated to active instance and that record will be discard from the draft. Once we add the valid value it will saved to active instance and removed from Draft.Database table.Draft table. Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
#mtb #sedona
