The primary purpose of defaulting action parameters is to enhance user efficiency by pre-filling form fields with relevant and context-aware values. This reduces manual data entry, minimizes errors, and ensures data consistency across the application. Implementing complex business logic within these defaulting actions adds a layer of intelligence to the application, enabling it to adapt to varying scenarios and user-specific requirements.

This blog post describes the different ways of defaulting action parameters in a Fiori Elements application built on the RAP framework. Earlier blog post can be referred to enable the parameters for an action.

1. Define the action in the base behavior with a function.
   Note : The function name must start with  GetDefaultsFor  and followed by action name.

     action ( features : instance, precheck ) Convert_Into_PC
       parameter ZRK_A_ActionParam_PR_To_PC result [1] $self
       { default function GetDefaultsForConvert_Into_PC; }​

2. Quick fix assistant can be used to create the method definition and implementation.

       METHODS convert_into_pc FOR MODIFY
         IMPORTING keys FOR ACTION _prhead~convert_into_pc RESULT result .​

       METHODS GetDefaultsForConvert_Into_PC FOR READ
         IMPORTING keys FOR FUNCTION _PRHead~GetDefaultsForConvert_Into_PC RESULT result.​

3. [ Optional ] Notice that the parameter of the action becomes the result of the function so that any changes in the action parameter can be reflected in the result of the function.
   
4. Enrich the method implementation with business logic in the function to default the values.
   Note : If it is a create or create by association action, then %cid needs to be used instead of %tky

     METHOD GetDefaultsForConvert_Into_PC.
   
       " Read the requisition header
       READ ENTITIES OF zrk_i_pur_req_h IN LOCAL MODE
         ENTITY _PRHead
         ALL FIELDS WITH CORRESPONDING #( keys )
         RESULT DATA(lt_pur_req).
   
       CHECK lt_pur_req IS NOT INITIAL.
   
       " Read the requisition item
       READ ENTITIES OF zrk_i_pur_req_h IN LOCAL MODE
           ENTITY _PRHead BY \_PRItem
           ALL FIELDS WITH CORRESPONDING #( keys )
           RESULT DATA(lt_pur_req_item).
   
       CHECK lt_pur_req_item IS NOT INITIAL.
   
       
       LOOP AT lt_pur_req ASSIGNING FIELD-SYMBOL(<fs_pur_req>).
         APPEND INITIAL LINE TO result ASSIGNING FIELD-SYMBOL(<fs_result>).
         
         " If it is create operation, then %cid needs to be used instead of %tky
         <fs_result>-%tky = <fs_pur_req>-%tky.
         
         <fs_result>-%param-description = |Created from { <fs_pur_req>-ObjectId }|.
               
         <fs_result>-%param-buyer = COND #( WHEN <fs_pur_req>-Buyer IS NOT INITIAL
                                            THEN <fs_pur_req>-Buyer
                                            ELSE sy-uname ).
                                            
         " Default the company code from the user attributes in the Org structure
         <fs_result>-%param-Company_code = zrk_cl_mng_pur_con=>determine_company_code( ).
         
         " Calculate the validity dates
         <fs_result>-%param-valid_from = cl_abap_context_info=>get_system_date( ).           
         <fs_result>-%param-valid_to = cl_abap_context_info=>get_system_date( ) + 365.
   
         " Take the first supplier from the requisition item
         LOOP AT lt_pur_req_item ASSIGNING FIELD-SYMBOL(<fs_item>)
           WHERE Supplier IS NOT INITIAL.
           <fs_result>-%param-supplier = <fs_item>-Supplier.
           EXIT.
         ENDLOOP.
         
         " If the supplier is not assigned to any item in PR, then determine from source of supply
         IF <fs_result>-%param-supplier IS INITIAL.
           <fs_result>-%param-supplier =
               zrk_cl_mng_pur_con=>determine_supplier_material( iv_material = VALUE #( lt_pur_req_item[ 1 ]-PartNo ) ).
         ENDIF.
       ENDLOOP.
   
     ENDMETHOD.​

5. Consume the function in the projection behavior for UI usage.

     use function GetDefaultsForConvert_Into_PC ;

6. Proceed with the action implementation to be executed based on the inputs. For more details on the implementation approach, please refer to the earlier blog.
7. The preview application is ready to be tested.
   
8. [ Optional ] Notice that the below annotation is already mapped in metadata which developers are supposed to write in BAS/WebIDE.

   <Annotations Target="SAP__self.Convert_Into_PC(SAP__self.PRHeadType)">
   <Annotation Term="SAP__core.OperationAvailable" Path="_it/__OperationControl/Convert_Into_PC"/>
   <Annotation Term="SAP__common.DefaultValuesFunction" String="com.sap.gateway.srvd.zrk_ui_pur_req.v0001.GetDefaultsForConvert_Into_PC"/>
   </Annotations>​

Additional notes:

• If there are multiple records selected in a list report page and different default values are determined, then the framework ignores the field and it will be blank.
• The function name must start with  GetDefaultsFor  and followed by action name.
• If it is a create or create by association action, then %cid needs to be used instead of %tky
• This feature is released as part of 2311 BTP release.

Conclusion:

ABAP RAP Defaulting action parameters with complex business logic empower Fiori Elements applications to be not just user-friendly but also intelligent and adaptable to the dynamic nature of business processes. The ability to customize defaulting actions according to specific business needs ensures a more seamless and efficient user experience.

References:

https://help.sap.com/docs/abap-cloud/abap-rap/operation-defaulting

https://community.sap.com/topics/abap/rap

For more similar content, Follow me on community or LinkedIn