Hello,

I would like to share my learnings so far as well as some of the best practices for
implementing determinations in RAP (ABAP RESTful Programming Model) so that
many of your queries are already solved before implementing determinations.

Syntax for determination:

determination DetName on modify/save { CRUD1; CRUD2; ... } | { field Field1,

Field2, ... ; }

Example:

1. There are 2 types of determination i.e. on modify and on save. On modify

determination will trigger before the save whenever the trigger conditions
specified in the brackets are fulfilled. On save determination will trigger at the
time of save whenever the trigger conditions specified in the brackets are
fulfilled. Few use cases for using determination on modify and on save:

 On modify -> When we need to calculate values of few fields

based on trigger conditions and show the calculated values to
user before save. Determination will be triggered before save
and on save as well whenever trigger conditions are fulfilled.

 On save -> When we need to calculate values of few fields

based on trigger conditions and show the calculated values to

1
 user after save. This may contain fields which are hidden at UI
level, but are used for some internal calculations. Determination
will be triggered only at save whenever trigger conditions are
fulfilled.

 Example:

2. Sometimes we implement determination on modify and it is getting triggered

but we can’t see the updated values on UI before save and we can see the
updated values on UI after save.
OR
Before save when we press enter on any field or refresh the page then only
we can see the updated values on UI.
This is because the side effects from UI are not getting triggered to show the
updated value on UI without save or refresh. To confirm this issue, check
network tab in browser developer tools. Get call to the entity (CDS) will not be
there after determination is triggered to refresh the data on UI with the latest
calculated values. Side effects on UI side on field update needs to be
implemented to solve this issue.

2
3. Many of us are confused about the trigger conditions to be written inside the
brackets. The trigger conditions can be any of the CRUD operations i.e.
create, update, delete or can be any field from the same entity. Few use
cases when to use CRUD operations or fields as trigger conditions in
determinations:

 Create -> Whenever an instance is created i.e. on creation of

new record / new line items based on the level of determination,
it will trigger the determination.

 Update -> Whenever an instance is updated i.e. any field value

is updated, it will trigger the determination.

 Delete -> Whenever an instance is deleted i.e. on deletion of a

record / line items based on the level of determination, it will
trigger the determination.

 Field -> Whenever value of that particular field (fields) is

updated, it will trigger the determination.

 Example:

3
4. Please note that we only need to specify trigger conditions while declaring the
determination in brackets. Please refrain from writing fields which needs to be
determined / calculated in the trigger conditions of that determination. I have
seen few determinations (not all) going in infinite loop as we are specifying the
calculated field in the trigger condition and changing the field inside that
determination which is resulting in application dumps. Example:

5. The trigger conditions can contain only fields of that entity. It cannot contain
fields of child / parent entity. In case we need a determination which needs to
be triggered on change of fields both at parent and child level, in that case
please create two determinations each at parent level and child level with the
corresponding trigger fields. Inside both the determinations you can write
same code and update the values of fields at any level (parent / child). So, the
restriction is only at the trigger conditions, but values can be updated of fields
at any level inside determination. Both the determinations will get called in any
random order, but the results will be same (as expected).

4
6. In addition to the last point, we can also create some sort of chain reactions.
We can create two determinations, one at parent level and one at child level.
Inside determination at child level we can modify the fields of parent level and
provide the same fields as trigger condition in parent level determination. This
way once the fields are updated at child level, this will trigger the
determination of parent level which will calculate and update the values of
parent fields. Example:

5
 7. Almost 90% of times we will be having trigger conditions as some fields.
Please use only that field (fields) as trigger conditions while implementing
determinations inside brackets. Refrain from using any other CRUD
operations (update, create, delete) along with the field while creating
determinations. If we specify any CRUD operation such as create or update
along with the fields as trigger conditions then the determination will be
triggered multiple times on each create/update of any other fields in the same
entity. By specifying only the fields as trigger condition will limit the call of
determination on change of that of field only and will save the extra
computation time and improve the application performance. In case we
specify the fields, it will be triggered on change of that field be it at the time of
creation or at time of update. Example:

8. In addition to the last point, when we are creating determinations on save and
we want the determination to trigger in case value of some field is updated
while creating new instance / record / line item, etc. then you will have to
specify the fieldname in trigger conditions as well as create operation. Else,
determination will not trigger at the time of creation. But, if we are using
determination on modify instead of save, then there is no need to specify
create operation with the fields. Example:

Rohan Bhateja