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