Skip to Content
Technical Articles
Author's profile photo Rohan Bhateja

Determinations in ABAP RESTful Programming Model


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, … ; }


  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 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.
    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.
  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:
  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).
  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:
  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:

Useful Links:

Please refer to SAP documentation on determinations for ABAP RESTful Application Programming Model for more details and examples by clicking here.

In case of any further questions, please leave a comment below and I will try to answer you asap. In case anyone wants to add something that I missed, please add in comments below.

Rohan Bhateja

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Pratik Vaidya
      Pratik Vaidya

      Thank you for this information Rohan. Very well explained.

      Author's profile photo Francisco José Carrasco Valverde
      Francisco José Carrasco Valverde

      Thank you Rohan.

      I'm wondering how to implement "Side effects on UI side on field update needs to be implemented to solve this issue" (point number 2).

      Could you help me out to manage ?


      Author's profile photo Vignesh Subramanian
      Vignesh Subramanian

      Hi Francisco José Carrasco Valverde

      For your question on how to add the Side effect annotations on UI side, please refer below screenshot. Please add annotations.xml file, incase if it is not present in the WebIDE project.

      Provide the field which is the trigger condition in Source property and field which has to be changed supposed to be present in Target Properties.

      Hope this helps!

      Thanks & Regards,


      Author's profile photo amr alaa
      amr alaa

      HI VIGNESH ,


      I tried it but not work , I am using Odata v2 , Is it the problem ?

      Author's profile photo Ramjee Korada
      Ramjee Korada

      Hi @fjcarrasco,

      See this blog if it helps. Side Effects are developed in business application studio.

      Best wishes

      Author's profile photo Vishnu Kothuru
      Vishnu Kothuru

      Hi Rohan,


      Thanks for the blog, interesting one.


      on Save:  I don't think this we will trigger after saving a record into DB. this will trigger whenever 'Save' action performed and determination conditions are fulfilled.


      In My case, I have a RAP(Managed with Draft) based Fiori app for a custom table, Now I have to call a FM once the record saved to custom table. I am not finding any determination point to call FM.

      Can you please let me know if you know determinations.




      Author's profile photo Sachin Artani
      Sachin Artani

      Hi Rohan,
      This is very helpful and neatly explained. Could you please let me know if we can make use of "on modify" determination to get the input value of a particular field (say from f4 value help) and make use of that value in the ABAP class?

      Author's profile photo Johannes Kretschmer
      Johannes Kretschmer

      Hi Rohan,

      thanks for the great artical:


      I have a question regarding "on modify".

      I setup several determation with on modify e.g.

      determination onModifytest1 on modify { field Field1; create; update; }
      determination onModifytest2 on modify { update; }
      determination onModifytest3 on modify { Field field2 }

      My expection would be , if i change a entry or field1 or field2 at the frontend one of this determation is triggered... but none of them are. Only if i press Save , all determation are triggered 2 times ?!?!?!

      So how can i react on User input on the frontend, if the determation "on modify" is only triggered after pressing save ?