Developing Transactional Apps

with
Draft Capabilities
ABAP RESTful Application Programming Model (RAP)
Part – 40

SAP TECHNOMANIAC
 Draft
➢The draft concept fills the gap between a
stateless communication pattern and a
stateful application by applying REST
principles:

• The draft represents the state and stores

the transactional changes on the database
in shadow tables.

• Between two backend roundtrips, there is

no running ABAP session waiting for the
next roundtrip.

SAP TECHNOMANIAC
 Draft Advantage

Save & Continue Later:

Staging: Save temporary Business data

Device Switch:

Collaboration : exclusive draft and shared draft

SAP TECHNOMANIAC
 Draft Basic Principles

The main business logic is implemented on the active entity,

for example with actions or feature control. This behavior can
be applied to draft entities in the same manner.

There can be only up to one draft instance for each active

instance at the same time.

The primary key value of a draft and the corresponding

active instance is the same.

SAP TECHNOMANIAC
 Draft is available for managed,
Unmanaged, mixed scenarios .

In all scenarios draft is managed Draft in

the RAP
In addition, RAP also offers
implementation exits for cases in
which you need business service-
specific draft capabilities that
impact the draft handling

SAP TECHNOMANIAC
 Draft Restrictions - Draft-Enabled Business Objects

There can be locking conflicts for the active provider

if an instance that was activated is locked again in the
same transaction. This is because the durable lock of
the active instance remains after the activation of a
draft instance.

Every child entity in a CDS composition hierarchy

must be represented in the behavior definition if a
behavior definition for the root entity exists and
defines a draft-enabled RAP business object.

SAP TECHNOMANIAC
 Draft Restrictions-Unmanaged Business Objects with Draft
There are features that can be defined in the behavior definition of an unmanaged
business object and thus used on active instances, but not on draft instances:
•Create-enabled associations that aren't modeled as part of a composition
•Direct creates on child instances

The aggregated admin data fields aren't Associations that use NOT in the
updated automatically when a draft binding condition can't be draft-
instance is saved. enabled.

There's no support for transactional Client-independent

draft-enabled associations leading from CDS views aren't
draft to active instances. supported.

SAP TECHNOMANIAC
 Development Flow

PROVIDING DEVELOPING EXPOSING ADDING EXPOSING

THE CDS TRANSACTIO THE DRAFT THE DRAFT-
DATA MODEL NAL MANAGED BO CAPABILITIES ENABLED
BASED ON BEHAVIOR FOR A UI TO THE BUSINESS
UUID KEYS FOR THE SERVICE MANAGED OBJECT FOR
MANAGED BO BUSINESS A UI SERVICE
OBJECT

SAP TECHNOMANIAC
 Editable Entities of the Business Object

➢/DMO/A_TRAVEL_D

➢/DMO/A_BOOKING_D

➢/DMO/A_BKSUPPL_D.

SAP TECHNOMANIAC
 We want to see internal managed early numbering so every
entity needs a field for the UUID key and this scenario will be
based on a UUID key layout

Each database table also has a semantic ID field are used to

semantically distinguish the entity instance in the business
object Travel Id , Booking Id…

The RAP managed runtime engine requires administrative data

fields for internal processing of the BO entities. Which will be
filled through annotation. These will be used as ETag, Total ETag

Table creation time

Considerations
SAP TECHNOMANIAC
 Creating CDS View Entities

/DMO/A_TRAVEL_D • ZR_Travel_D

/DMO/A_BOOKING_D • ZR_Booking_D

/DMO/A_BKSUPPL_D. • ZR_BookingSupplement_D

SAP TECHNOMANIAC
 Creating CDS View Projections

/DMO/A_TRAVEL_D • ZR_Travel_D ->ZC_Travel_D

/DMO/A_BOOKING_D • ZR_Booking_D->ZC_Booking_D

/DMO/A_BKSUPPL_D.
• ZR_BookingSupplement_D
->ZC_BookingSupplement_D

➢ Service Definition -> ZUI_TRAVEL_A_D

➢ Service Binding -> ZUI_TRAVEL_A_D_O2

SAP TECHNOMANIAC
 Let's Do Practical

SAP TECHNOMANIAC
 Development Flow

Providing the Developing Exposing the Adding draft Exposing the

CDS data transactional managed BO capabilities to draft-enabled
model based behavior for for a UI the managed business
on UUID keys the managed service business object for
BO object a UI service

SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
(Authorization )

ABAP RESTful Application Programming Model (RAP)

Part – 41

SAP TECHNOMANIAC
 Development Flow

Providing the Developing Exposing the Adding draft Exposing the

CDS data transactional managed BO capabilities to draft-enabled
model based behavior for for a UI the managed business
on UUID keys the managed service business object for
BO object a UI service

SAP TECHNOMANIAC
 Authorization Checks for Read Operations :- DCL used

• Read from Transactional buffer DCL evaluated by framework in

Managed Scenario
• In Unmanaged we have to check DCL in Read method
• You can't define authorization control for functions.

Authorization Checks for Modify Operations :- BDL

• Using Authorization, We can prevent Modify operation on transactional

buffer these methods are called before the actual modify request is
executed
• It isn't possible to check the authorization of a user against the
incoming values (Precheck Can be used) bz Authorization checks
in RAP authorization control methods can only check against the state
of the BO before the request was executed.

Authorization Control
SAP TECHNOMANIAC
 Global Authorization:- Instance Authorization:-

• Global authorization is used for all • You can define instance

authorization checks that only authorization that depends on a
depend on the user. field value of the instance.
• You can define global authorization (Manager change own emp salary)
to check if users are allowed to • Operations that don't operate on a
execute an operation in general. specific instance can't be checked
(HR can create Employee) with instance authorization. Create
• It checks can be implemented for and Static Action (We need key
both, static, and instance-bound static don’t have key)
operations. (Approve all pending
SO)

Authorization Control
SAP TECHNOMANIAC
 Authorization Control

➢Authorization Check against Incoming Values :-

• Authorization checks can be implemented in the corresponding
precheck method for the operation to check against incoming values.
• In this case, the unwanted values don't even reach the transactional
buffer.

SAP TECHNOMANIAC
 RAP - Authorization
➢Each RAP BO entity must be
declared as authorization
master entity or as
authorization dependent entity
using the syntax
➢The RAP BO root entity must
be defined as authorization
master entity. All other RAP
BO entities can be either
authorization master or
authorization-dependent
entities.

SAP TECHNOMANIAC
 ◦authorization:none
The authorization control that is defined for a RAP BO ◦authorization:update
entity applies to all RAP BO operations of that
◦authorization:global
particular entity.
◦authorization:instance

◦actions of authorization dependent entities

In the following cases, the authorization control ◦create-enabled cross-BO associations
must be implemented in separate methods ◦create-enabled associations which are not to-child
associations

•If a root entity is defined as authorization master entity, then it is recommended that each child entity that is
behavior-enabled is defined as an authorization dependent entity.

RAP - Authorization
SAP TECHNOMANIAC
 Managed RAP BO • RAP Framework checks for Global and instance Authorization

• If global authorization control is specified, the RAP framework checks each

RAP BO operation
• The RAP framework does not call the method for instance authorization in
Unmanaged unmanaged non-draft scenarios. If authorization control is relevant, it
RAP BO must be implemented in the respective method for each modify operation.
• Only in UI scenarios, the instance authorization control method has an
effect on the RAP consumer hints.

RAP – Authorization
Availability
SAP TECHNOMANIAC
 Generally, CRUD operations and actions reused with use inherit the authorization
control from the base behavior definition

If you define new actions on projection level as described in Actions and Functions in
Projection Behavior Definitions and the projection behavior definition is defined as
strict, you can add authorization control for these actions on projection level

There's no master/dependent relation between the different projection definitions.

Additionally, you can define an action with authorization:none to exclude it from

authorization checks.

RAP – Authorization Availability

Projection Behavior Definitions
SAP TECHNOMANIAC
 Consumer Hints in UI Scenarios
Example :- The action
SetStatusBooked can only be
executed for instances, whose
Action and other operation buttons status isn't booked yet (feature
are only clickable if authorization control) and by users that are
and feature control methods assigned to a specific role
provide a positive result under the (authorization). When selecting
current condition instances, whose status is booked
already, the button for this action
isn't available on the UI and the
user can't execute the action.

SAP TECHNOMANIAC
 Let's Do Practical

SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Authorization in Draft Scenarios

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
(Authorization Implementation)

ABAP RESTful Application Programming Model (RAP)

Part – 42

SAP TECHNOMANIAC
 Global Authorization
Implementation
➢Global :- Restrict if user don’t have access to create,
Update, Delete access
➢We will use existing ‘/DMO/TRVL’ Auth object

SAP TECHNOMANIAC
 Let's Do Practical

SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
(Abstract Entity and Actions )

ABAP RESTful Application Programming Model (RAP)

Part – 43

SAP TECHNOMANIAC
 Input Parameter in Actions
➢The input parameter for an action or function is
defined with the keyword parameter.
➢The input parameter entity ParameterEntity
can be a CDS abstract entity or a classic DDIC
type
➢Input parameters with $self are only allowed
on static actions or functions(result type is the
same type as the entity for which the action or
function is defined)

SAP TECHNOMANIAC
 Output Parameter in Actions
➢The output parameter for an action or function is
defined with the keyword result.
➢If a result parameter is declared it must be filled
inthe implementation in the ABP.
➢Cardinality :- This is a mandatory addition.

SAP TECHNOMANIAC
 Not created as a
Represents a data type. database object hence Abstract entities are
Thes are CDSCDS transient
transient entities

entities.
CDS transient client handling is not non-SQL CDS entities.
defined.
entities

In the context of the

RAP, abstract entities A CDS abstract entity The DDL source code of
DDL source code

are used as parameters can be used as a global a CDS abstract entity

for RAP actions, RAP structured type in ABAP must have the same
functions, and RAP programs name as this entity.
business events.

CDS-Abstract Entity
SAP TECHNOMANIAC
 CDS-Abstract Entity

SAP TECHNOMANIAC
 acceptTravel :- The action sets the rejectTravel :- The action sets the
travel status to Accepted (A). travel status to Rejected (X).

deductDiscount :- The action

calculates a new travel price by
deducting a discount for the
reCalcTotalPrice :- The action
BookingFee. The consumer can
calculates the total price for one
freely choose the percentage that
travel instance
is deducted. The value must be
passed together with the action
request.

Developing Actions
SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
( Actions Implementation )

ABAP RESTful Application Programming Model (RAP)

Part – 44

SAP TECHNOMANIAC
 Let's Do Practical

SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
(Determinations & Side Effect )

ABAP RESTful Application Programming Model (RAP)

Part – 45

SAP TECHNOMANIAC
 Determinations
➢A determination is an optional part of the BO behavior that
modifies instances of BO based on trigger conditions
➢A determination is implicitly invoked by the BO’s framework
if the trigger condition of the determination is fulfilled.
➢Trigger conditions can be modify operations CUD and
modified fields
➢An invoked determination can compute data, modify entity
instances according to the computation result and return
messages to the consumer by passing them to the
corresponding table in the REPORTED structure.

SAP TECHNOMANIAC
 RAP - determination
➢Trigger conditions can be modify operations CUD or modified fields

➢Two types of determinations are distinguished, depending on the stage of

the program flow the determination is executed:
• on modify :- It is executed immediately after data changes take place in the
transactional buffer so that the result is available during the transaction.
• on save :- It is executed during the save sequence at the end of an transaction, when
changes from the transactional buffer are persistent on the DB.
➢For determinations defined as on save, update works
only in combination with the trigger operation create

SAP TECHNOMANIAC
 Determinations Points
➢The determination result must not change if the
determination is executed several times under the same
conditions (idempotence).
➢The execution order of determinations is not fixed. If there is
more than one determination triggered by the same
condition, you cannot know which determination is executed
first.
➢Once a determination has been triggered, it must run
independently from other determinations.

SAP TECHNOMANIAC
 Developing Determinations
Travel entity

➢setTravelNumber :- To fill semantic ID it should be read only

➢setStatusToOpen :- The travel is set to Open when a new instance
is created.
➢calculateTotalPrice

Booking entity

➢setBookingNumber :- To fill semantic ID it should be read only

➢setBookingDate:- It should be read only and should set internally
➢calculateTotalPrice

Booking supplement entity

➢setBookSupplNumber :- To fill semantic ID it should be read only

➢calculateTotalPrice

SAP TECHNOMANIAC
 Let's Do Practical

SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
( Side Effect )

ABAP RESTful Application Programming Model (RAP)

Part – 46

SAP TECHNOMANIAC
 The SAP Fiori UI doesn't necessarily trigger a reload of all related BO properties after
every user input, as it simply doesn't know anything about data changes on the tables.

Side effects are used to reload data, permissions, or messages based on data
changes in UI scenarios with draft-enabled BOs.

Side effects are translated into annotations in the OData metadata of a RAP service. An
implementation in an ABAP behavior pool is not required.

These are available from 2302 of the SAP BTP, ABAP Environment and SAP S/4HANA
ABAP Environment

Side Effects
SAP TECHNOMANIAC
 Side Effects - Trigger

➢Field field MyField :- Whenever a

defined field is changed on the user
interface
➢$self :- Whenever the current RAP
BO entity is modified using a CUD
operation
➢Action action MyAction :-Whenever
the action is executed on the user
interface
➢determine action determine action
MyDetermineAction :- Whenever the
defined source Sources is changed,

SAP TECHNOMANIAC
 RAP - side effect, Targets
1. ... field ...

2. ... permissions ...

3. ... $self

4. ... entity

5. ... messages

SAP TECHNOMANIAC
 RAP - side effect, Target Field

➢All Field defined will be reloaded

➢The asterisk * reloads all fields of the same entity instance.
➢It is also possible to specify fields from other entity
instances as targets.

SAP TECHNOMANIAC
 RAP - side effect, Target
permissions
➢The feature and authorization control of the specified
properties are reloaded when the side effect is triggered.
➢Multiple permissions can be listed in parentheses, separated
by commas
• Example: permissions(action MyActionFC, update).

SAP TECHNOMANIAC
 RAP - side effect, Target
➢$self
• The current RAP BO entity is reloaded.
• Limitation: In case of the trigger property $self, it is not allowed to
specify the current entity $self as target.
➢entity _MyAssoc
• The specified associated entity _MyAssoc is reloaded when the side
effect is triggered.
➢message
• All messages stored in the response parameter reported are reloaded
when the side effect is triggered.

SAP TECHNOMANIAC
 RAP - side effect, Targets
➢One type of side effect can affect multiple targets.

➢It is possible to group multiple targets using parentheses.

SAP TECHNOMANIAC
 Restriction

➢Static actions defined using the addition static must not

be used as a side effect trigger, nor as a side effect
target.
➢Limitation: In case of the trigger property $self, the
target cannot be a field of the current entity $self.
However, fields from associated entities can be defined
using path expressions.

SAP TECHNOMANIAC
 Side Effect in BDL
➢Side effects can be specified exactly once for each RAP
BO entity in the entity behavior definition.
➢Multiple side effects can be summarized within curly
brackets, separated by a semicolon (;), if required.

SAP TECHNOMANIAC
 RAP - use, Projection and
Interface BDEF
➢The syntax use side effects is specified in the behavior
definition header and all side effects from all RAP BO
entities of the underlying RAP BO are reused

SAP TECHNOMANIAC
 Let's Do Practical

SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
( State vs Transition Messages & Validations )

ABAP RESTful Application Programming Model (RAP)

Part – 47

SAP TECHNOMANIAC
 Messages -RAP

State messages :- ➢ The termination at runtime due to errors

must always be implemented depending
• Refer to the state of a business on entries in the fail structure that
object instance indicate the failure cause.
• State messages must always be ➢ Messages as part of the reported
bound to a business object instance structure only offer additional
information about the respective
circumstances but aren't reliable
Transition messages :- indications for termination at runtime.

• Refer to the current request ➢ It's always recommended to consider

the failure cause in the fail structure for
• It can either be bound or unbound the program design.
(not related to a business object
instance).

SAP TECHNOMANIAC
 Messages in RAP -Implementation

➢ %TKY :- Used for uniquely identify to which instance a message belongs.

• State messages - If state messages are accessed via EML, the respective
messages can only be returned if the %TKY of the instance is known.
• Transitions messages :- The %TKY is required for the framework to resolve a
%element-field1 target assignment. If a transition message doesn't have a
%TKY, the target isn't resolved in an OData response and the message is
interpreted as unbound transition message by the framework.

SAP TECHNOMANIAC
 Messages in RAP -Implementation

➢ %element :- This improves the user experience, as it enables navigation and

clear allocation of errors when there are multiple error messages
➢ %op-create/%action-action1: If more than one operation is executed for
the same entity instance in one EML or OData call, the %op-indicator is relevant
to map the messages to the corresponding operations.
➢ %path :- If f there’s a business object with several child entities, the %PATH
component is extended to map the child entity to its parent and the business
object root.
SAP TECHNOMANIAC
 Messages in RAP -Implementation

➢ %state_area (only relevant for state messages): This message is identified

as state message since this component is filled .For a transition message, this
component isn’t filled.
➢ REPORTED-BUSINESS_OBJECT_ENTITY: This message is bound since it’s
allocated to a specific business object entity. Unbound messages are allocated to
the %other component instead of a specific entity.
➢ Longtexts: If a message has a longtext, the longtext is automatically displayed
on the UI together with the message and no additional implementation is
required.
SAP TECHNOMANIAC
 Transition Messages
➢ Transition messages refer to a triggered
request and are only valid during the
runtime of the request.
➢ In contrast to state messages, they don't
have any relation to the state of the
business object itself, but instead to the
transition between states.
➢ Instance-bound transition messages
➢ Entity-bound transition messages
(Global)
➢ Generic Message Implementation:
Unbound Transition Message

SAP TECHNOMANIAC
 A state message must
You musn't define state
State messages are always be bound to a
messages in an action or
semantically related to the business object entity and
function added on projection
state of business object can't be allocated to the
level (Dump)
%OTHER component.

If a validation returns an
error message regarding an
Draft scenario, they’re
Managed scenario, the incorrect value in a field, the
persisted until the state that
messages are buffered until state message is persisted
caused the message is
the end of the session until the value is changed
changed
and the save sequence is
triggered again

State Messages
SAP TECHNOMANIAC
➢The %state_area
Component
➢The %path Component for
Child Entities
➢Invalidating State
Messages

SAP TECHNOMANIAC
State Messages
Using state messages is only recommended for
the following cases:

Business Object with Draft Capabilities:

Determinations and Validation that are
allocated to the PREPARE or a determine
action

Unmanaged Business Object:

Finalize/Check Before Save Code Exit

Managed Scenario:
Determinations/Validation on Save

SAP TECHNOMANIAC
 State Message

➢Using state messages is only recommended for the

following cases:
• Business Object with Draft Capabilities: Determinations and
Validation that are allocated to the PREPARE or a determine
action
• Unmanaged Business Object: Finalize/Check Before Save
Code Exit
• Managed Scenario: Determinations/Validation on Save

SAP TECHNOMANIAC
 Message Behavior in EML

➢Transition Messages :- The transition message is

returned with the REPORTED structure of the same
statement.
➢State Messages :- State messages aren't returned
with the REPORTED structure of the EML request that
changes the state of the business object, but can
instead only be accessed via a READ.

SAP TECHNOMANIAC
 Messages in OData V4

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
( Validations & State vs Transition Messages )

ABAP RESTful Application Programming Model (RAP)

Part – 48

SAP TECHNOMANIAC
 RAP - validation
➢A validation is an optional part of the business object behavior that checks
the consistency of business object instances based on trigger conditions.
➢It is automatically invoked by the RAP framework if the trigger condition of
the validation is fulfilled
➢Trigger conditions can be :- CUD operation or modified fields (update for
validations is only supported in combination with create)

➢Validations are always invoked during the save sequence at the end of a
transaction and this is indicated by the mandatory addition on save.
➢Validations must be implemented in the RAP handler
method FOR VALIDATE in the local ABAP
behavior pool (ABP).

SAP TECHNOMANIAC
 RAP - validation

➢The execution order of validations is not fixed. If there is more than

one validation triggered by the same condition, the execution order is
not predictable.
➢It is not allowed to use EML MODIFY statements in the implementation
of validations.
➢An error message can be written to the reported structure of the
MODIFY ENTITIES statement.
➢An entry is returned in the failed and reported structures of the
COMMIT ENTITIES statement.

SAP TECHNOMANIAC
 Trigger Time
➢ Validations on save are executed:
• In the checkBeforeSave method of the save sequence
• On request by executing a determine action, if the validation has been assigned to
such an action in the behavior definition. For more information, see Determine
Actions.

SAP TECHNOMANIAC
 Validating for the Travel Entity

SAP TECHNOMANIAC
 Validating for the Booking Entity

SAP TECHNOMANIAC
 Validating for the BookingSuppl
Entity

SAP TECHNOMANIAC
 Let's Do Practical

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
( Adding Draft Capabilities to Managed BO )

ABAP RESTful Application Programming Model (RAP)

Part – 48

SAP TECHNOMANIAC
 The addition with draft enables RAP draft handling for a
business object

It is added in the behavior definition header as it draft-

enables the entire business object. RAP-with
RAP draft handling is in all scenarios completely managed by
draft
the RAP transactional engine.

The application developer is not responsible for how draft data

is written to the draft database table.
draft database table

•Managed RAP BO •Unmanaged RAP BO

Availability •In projection BDEFs and in interface
BDEFs, use draft

SAP TECHNOMANIAC
 Let's Do Practical

SAP TECHNOMANIAC
 Draft table: To store draft instance

Total etag: Indicates changes between the active and the draft version

Draft actions: They allow data to be manipulated on the RAP draft table.

Draft-enabled associations: A draft-enabled association retrieves active data if it

is followed by an active instance and draft data if is followed by a draft instance

Draft - Dependencies
SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
( Draft Table, Total Etag, Draft Action )

ABAP RESTful Application Programming Model (RAP)

Part – 50

SAP TECHNOMANIAC
 Draft Database Table
➢A RAP draft table is a DDIC database table used
to store draft data
➢The draft table must reflect the fields of the
underlying CDS entity
➢The first field must be a client field that has the
data type CLNT.
➢The field names of the fields of the draft tables
are the same as the field names of the
underlying CDS entity. If the CDS entity has
assigned alias names, these alias names must be
used.
➢The data types and field lengths must match
exactly.
➢Additionally, the draft table must contain some
technical information the RAP transactional
engine needs to handle the draft. Using draft
admin include SYCH_BDL_DRAFT_ADMIN_INC.

SAP TECHNOMANIAC
 Draft Database Table
While the active database table stores many instances, but
rarely has access on these instances, it is vice versa for the
draft table.

During runtime, every request is marked whether it is intended

for the draft table, or for the active with the draft indicator
%IS_DRAFT.

Access with ABAP SQL and AMDP is technically possible, but not
recommended. It is recommended that a draft table is accessed
using the RAP framework only, for example, with EML, so that
the draft metadata get updated automatically.

SAP TECHNOMANIAC
 Total-ETag

Its value is compared

This Total-Etag field
It enable optimistic when resuming a draft
on the database table
concurrency checks instance to ensure that
is updated by the RAP
during the transition the active data has not
runtime framework as
from draft to active been changed after the
soon as an active
data. exclusive lock has
instance is changed.
expired

SAP TECHNOMANIAC
 Total-ETag Update
The RAP managed framework is able to update the total ETag field automatically on saving a draft instance if the following
conditions are fulfilled:

The total ETag field is included in the field-mapping

The field is annotated in CDS with the annotation
prescription in the behavior definition, if the names
@Semantics.systemDateTime.lastChangedAt: true
on the database table and in CDS are different.

If you don’t enable the framework to update the field, you have to include your own updating logic in the
business logic of the BO.

SAP TECHNOMANIAC
 Total ETag vs ETag

Total ETag ETag

➢The total ETag is used for edit-drafts, ➢The ETag concept ensures that the end user
a draft that has a corresponding of an OData service only changes instances
active instance with the state that is displayed on the UI.

➢As soon as the exclusive lock expires ➢Hence, the ETag prevents changes of the BO
and an edit-draft is resumed, the total that are not noticed by the OData consumers
ETag value of the draft instance is
compared to the total ETag value on
the active instance. ➢With ETag master, each BO entity can be
checked independently.
➢The total ETag is compared for all
entities of a BO

SAP TECHNOMANIAC
 Draft-Enabled Associations

A draft-enabled association retrieves active data if it is

followed from an active instance and draft data if it is
followed from a draft source instance.

As soon as you draft-enable a BO by adding with draft,

all BO-internal associations are automatically draft-
enabled.

SAP TECHNOMANIAC
 RAP - draft action
Draft actions are available for draft-enabled RAP BOs
only.

They allow data to be manipulated on the RAP draft

table.

Draft actions must be specified for lock master entities

that are defined using the keyword lock master only

An implementation in the ABP is not required.

However, the optional addition with additional

implementation is available for some draft actions.

SAP TECHNOMANIAC
 RAP - draft action Availability

Managed and Unmanaged and

draft-enabled draft-enabled
RAP BOs RAP BOs
(mandatory). (mandatory).

In projection In RAP BO
BDEFs that interfaces that
reuse RAP draft reuse RAP draft
handling, the handling, the
draft actions draft actions
must be reused must be reused

SAP TECHNOMANIAC
 RAP - draft action

➢draft action Edit

➢draft action Activate
[optimized]
➢draft action Discard
➢draft action Resume
➢draft determine action Prepare
➢draft action AdditionalSave

SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
( Draft Runtime & Draft Action )

ABAP RESTful Application Programming Model (RAP)

Part – 51

SAP TECHNOMANIAC
 Draft Runtime
➢All data undergo several states while being processed
by a draft business object. There are three distinct
states

• New-draft instance
• Active instance
• Edit-Draft instance

SAP TECHNOMANIAC
 New-draft instance
➢ Initial data that is not yet persisted on the active database table
➢ New-draft instances do not have a corresponding active instance
➢ They are created using the modify CREATE operation having the draft
indicator %IS_DRAFT set to true

SAP TECHNOMANIAC
 Active instance
➢ Active instances are created by activating new draft instances or using the
modify CREATE operation with the draft indicator %IS_DRAFT set to false
➢ The data that is stored on the persistent database table is called active data

SAP TECHNOMANIAC
 Edit-Draft instance
➢ Edit-drafts always exist in parallel to the corresponding active data.
➢ Whenever active data is edited, the active instance is copied to the draft table.
➢ All modifications are saved on the draft DB table before the changes are finally
applied to the active data on the active DB table again

➢ Edit-draft instances
are created by
using the EDIT
action on active
instances.

SAP TECHNOMANIAC
 Locking During Draft
When working with draft instances, an exclusive lock is set on
the instance. For edit-drafts, this prevents any other user from
Exclusive lock modifying the corresponding active instance
In case of a new-draft, the primary key number is locked
exclusively to avoid duplicate key failure on the database.

After the exclusive lock has expired, the draft is in an

optimistic lock mode, in case the user starts processing
Optimistic lock again, the draft resume action is automatically invoked.
It locks the corresponding active instance again, compares
the total ETag and if successful, the draft can be continued in
exclusive mode

SAP TECHNOMANIAC
 Creating Draft Data
“Modify CREATE Request”
➢Using EML with %is_draft =
true
➢On a Fiori Elements UI,
clicking the Create button
sends a CREATE request with
the draft indicator set to true,
so active instances cannot be
created directly this way.

SAP TECHNOMANIAC
 Creating Draft Data
“Edit Action”
➢An edit action creates a new draft document by automatically copying the
corresponding active instance data to the draft table.
➢At the same time, the EDIT triggers an exclusive lock for the active
instance
➢The edit action has a parameter preserve_changes,if it is set to true, your
action request is rejected if a draft already exists. If preserve_changes is
set to false (default setting), the edit action is executed.
➢Instance authority and feature control are both checked for the action.
➢Trigger:-
• Fiori Edit button ( preserve_changes set to true).
• EML

SAP TECHNOMANIAC
 Runtime Edit Action
SAP TECHNOMANIAC
 Runtime CREATE Draft

SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Developing Transactional Apps
with
Draft Capabilities
(Draft Runtime & Draft Action )

ABAP RESTful Application Programming Model (RAP)

Part – 52

SAP TECHNOMANIAC
 Draft Runtime & Draft Action

SAP TECHNOMANIAC
 Creating Active Data
“Modify CREATE Request”
➢Using EML with %is_draft =
false
➢Creating a new active
instance for a draft BO
from scratch is not
possible from a Fiori
Elements UI.

SAP TECHNOMANIAC
 Creating Active Data
“Activate Action”
➢By executing the draft action ACTIVATE on a draft instance, you copy the draft instance to
the active application buffer
➢Once the active instance is successfully created or updated, the draft instance is discarded
➢The activate action does not save the active instance on the database. The actual save is
executed separately, either by COMMIT ENTITIES via EML or by calling the save sequence
in case of OData.
➢The activate action is only possible on draft instances.
➢On a Fiori Elements UI, the activate action is triggered when choosing the Save button after
editing data. It triggers the save sequence after the activation.

SAP TECHNOMANIAC
 Creating Active Data
“Activate Action”

SAP TECHNOMANIAC
 Runtime Activate Action

SAP TECHNOMANIAC
 Runtime Activate Optimized Action
Draft activation

➢Without optimization
• When draft instances are
modified, determinations
on modify are executed if
their trigger conditions are
met. In the activate variant
without optimization, these
determinations are executed
again during draft activation,
when the RAP runtime takes
over the changes from the
draft instances to the active
instances.

SAP TECHNOMANIAC
 Runtime Activate Optimized Action
Draft activation

➢With optimization
• In the optimized variant, the
determinations on modify are
not executed again on the
active instances during draft
activation. Determinations on
modify that are triggered by
determinations on save
during Prepare are skipped
as well.

SAP TECHNOMANIAC
 Runtime Activate Optimized Action
Save after draft activation

➢Without optimization
• After activating a draft
instance, determinations and
validations with the trigger
time on save are executed
during the save sequence

SAP TECHNOMANIAC
 Runtime Activate Optimized Action
Save after draft activation

➢With optimization
• Those determinations and
validations that have been
executed as part of the draft
determine action prepare
before activating the draft
instance are not executed
again when saving the active
instance.

SAP TECHNOMANIAC
 Runtime Activate Optimized Action

➢The optimizations outlined above are 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.

SAP TECHNOMANIAC
 Changing and Reading Instances of
a Draft BO
➢Updating Instances of a Draft BO
➢Executing Actions on a Draft BO
➢Reading Instances of a Draft BO

SAP TECHNOMANIAC
 Changing and Reading Instances of
a Draft BO
➢Updating Instances of a Draft BO
• Fields of draft BO instances are changed by the modify
request for UPDATE.
• Fiori Element UI
• EML

SAP TECHNOMANIAC
 Changing and Reading Instances of
a Draft BO
➢Executing Actions on a Draft BO
• Actions on draft business objects are executed by modify
requests for action execution.
• Fiori Element UI
• EML

SAP TECHNOMANIAC
 Changing and Reading Instances of
a Draft BO
➢Reading Instances of a Draft BO
• Business object instances of a draft BO are read by a read
request.
• Fiori Element UI
• EML

SAP TECHNOMANIAC
 Runtime MODIFY Draft
SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC
 Deleting Instances of a Draft BO

➢Discarding Root Draft Instances

• delete the draft instance from the draft database table.
• exclusive locks are released. (no impact on active instance)
➢Deleting Root Active Instances :-
• Standard operation DELETE along with discard if draft is there

SAP TECHNOMANIAC
 Runtime Discard Action

SAP TECHNOMANIAC
 Preparing Draft Instances for
Activation
➢The draft determine action PREPARE is executed automatically at
least once before draft data is activated during the activate
action
➢It ensures that the draft instance is consistent by calling the
validations and determinations on save that are specified for the
prepare action in the behavior definition.
➢The prepare action can only be executed on draft instances.
➢On a Fiori Elements UI, the PREPARE action is invoked by
choosing Save on a draft instance. The UI then sends the request
for PREPARE before executing the action ACTIVATE.

SAP TECHNOMANIAC
 Runtime Prepare Action

SAP TECHNOMANIAC
 Resuming Locks for Draft
Instances
➢The draft action RESUME is executed automatically
whenever there is a modification on a draft instance
whose exclusive lock has expired.
➢It recreates the lock for the corresponding active
instance on the active database table.
➢On a Fiori Elements UI, the action is invoked when the
user chooses a draft instance and continues with editing
data if the exclusive lock is expired.

SAP TECHNOMANIAC
 Runtime Resume
Action

SAP TECHNOMANIAC
 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 re-creates the lock for the corresponding entity instance
on the active database table. It is executed automatically
whenever there is a modification on a draft instance whose
exclusive lock has expired.
➢In case of edit-draft instances, the same feature and
authorization control is executed as defined for the draft
action Edit.
➢The optional addition with additional implementation is
available.

SAP TECHNOMANIAC
 Saving Data to the Database
➢Draft data does not have to be in a consistent state to be saved.
➢No validations are triggered when saving draft data to the draft database
➢The save sequence of the active provider is not triggered. That means, there is no Finalize
and no Check_Before_Save when saving draft instances on the draft database table.
➢On a Fiori Element UI, the state of the application buffer is saved to the draft database table
whenever the input fields are edited. This is done for each field separately. That means, after
leaving one input field, the data is transferred to the draft database table. The UI displays
the message Draft saved after each roundtrip.

SAP TECHNOMANIAC
 THANK YOU
CONTACT
Ram Niwas

LinkedIn :- https://www.linkedin.com/in/ram-niwas-04/

FB group :-
https://www.facebook.com/groups/586730659057346/

GitHub for all the Code :- https://github.com/ramniwas04

SUBSRIBE LIKE COMMENT

SHARE THANKS

SAP TECHNOMANIAC