RAP Interview Questions

  READ ENTITIES OF /DMO/R_Travel_D IN LOCAL MODE
      ENTITY Travel
        FIELDS (  BeginDate EndDate TravelID )
        WITH CORRESPONDING #( keys )
      RESULT DATA(travels)
      FAILED DATA(failed)
      REPORTED DATA(reported).

// The addition IN LOCAL MODE ensures that a BO is accessed directly without checking access control, authorization control or feature control or prechecks. 

What is Instance Feature Control in RAP?

An instance feature in ABAP RAP is a dynamic control that determines the state of an UI element (like a button or field) for a specific record (instance) based on its data. A common example is a “Set to Booked” button in a travel application that is only enabled for a travel instance if its status is not already “Booked”. To implement this, you declare the action with features:instance in the behavior definition and then implement the get_instance_features method in the behavior implementation class to return the feature’s state for each specific instance.

// Behaviour Definition Example
ACTION ( features : instance ) SetStatusToBooked result [1] $self;

// Behaviour Implementation Example

// get_instance_features definition
METHOD get_instance_features FOR INSTANCE FEATURES IMPORTING keys REQUEST requested_features FOR travel RESULT result.


// get_instance_features implementation
METHOD get_instance_features
  " Logic to determine feature state based on instance data goes here
  " Example: Enable the button only if the status is not 'Booked'
  READ ENTITIES OF zi_travel IN LOCAL MODE
    ENTITY Travel
    FIELDS ( Status )
    WITH CORRESPONDING #( keys )
    RESULT DATA(travels).

  LOOP AT travels ASSIGNING FIELD-SYMBOL(<ls_travel>).
    DATA(lv_is_booked) = <ls_travel>-Status = 'Booked'.
    IF lv_is_booked = abap_true.
      result[ 1 ]-%setstatus_to_booked-%active = abap_false. " Button disabled
    ELSE.
      result[ 1 ]-%setstatus_to_booked-%active = abap_true.  " Button enabled
    ENDIF.
  ENDLOOP.
ENDMETHOD.

What is Value Help with Additional Binding?

We use an additional binding to define more than one binding condition between the source view and the value help provider. The value help is then automatically filtered by the additional binding. It proposes only entries that match the additional binding. This additional binding can either be another element or a parameter. These need to be present in the source view and in the value help provider view. When an entry is selected in the value help provider, the values of both binding elements are transferred to the input fields of the source CDS view.

The value help provider view contains the connection ID and the carrier ID, for which a mapping condition is defined.
define view /DMO/I_Connection_VH as select from /dmo/connection 
{
key carrier_id, 
key connection_id, 
airport_from_id, 
airport_to_id, 
departure_time, 
arrival_time, 
distance, 
distance_unit
}


define view /DMO/I_Booking_VH as select from /dmo/booking 
{… 
    @Consumption.valueHelpDefinition: [{ entity: {name: '/DMO/I_Connection_VH' , element: 'connection_id' },
                   additionalBinding: [{ localElement: 'CarrierID', element: 'carrier_id', usage: #Filter }]
                }]
connection_id as ConnectionID, 
… }

What is the use of Strict Mode in the Behaviour definition?

managed implementation in class cl_bp_r_budgetdocumenttp unique;
strict ( 2 );
with draft;

BDEF strict mode applies additional syntax checks to RAP behavior definitions. It ensures, for example, that no outdated syntax is used, implicitly available operations are declared explicitly, and the RAP BO in question complies to best practices. BDEF strict mode is provided by the RAP framework, no implementation in an ABAP behavior pool is required. Currently, the following versions of strict mode are available:

Strict mode version 1, specified using strict
Strict mode version 2, specified using strict(2)
Strict mode version 2 covers all rules from strict mode version 1, plus some additional checks.

How to define an API class in RAP?

Class Zcl_student_api_class definition
PUBLIC
FINAL
CREATE PUBLIC.

PUBLIC SECTION.
// create constructor
CLASS METHODS: get_instance 
         RETURING VALUES (ro_instance)
         TYPE REF TO Zcl_student_api_class .

PROTECTED SECTION.
PRIVATE SECTION.
 CLASS DATA mo_instace TYPE REF TO Zcl_student_api_class .
Class Zcl_student_api_class IMPLEMENTATION.

METHOD get_instance .
mo_instance  = ro_instance = COND #( WHEN mo_instance is BOUND
                                     THEN mo_instance 
                                     ELSE new #( )).

END METHOD.

ENDCLASS.

What is early Numbering in an Unmanaged scenario?

Early numbering is implemented by adding the keyword EARLY NUMBERING in the entity.
Automatcilly assign a key to Bussiness Object Entity inatance during Create , create by Association.
Keys are genrated in interaction phase of RAP.

// Create method gets genrated if EARLY NUMBERING key word is used in BDEF.
METHODS earlynumbering_create FOR NUMBERING 
        IMPORTING ENTITIES for CREATE students.

//  Create By Assocoation is genrated if Assocoation is there
METHODS earlynumbering_cba_results FOR NUMBERING 
        IMPORTING ENTITIES for CREATE students/_Results.

What is Late Numbering?

• The RAP runtime engine assigns values to the primary key fields.
• In the ABAP behaviour pool, the RAP saver method adjust_numbers must be implemented to assign a final primary key value for each entity instance.
• The key value for an instance is assigned just before the instance is saved on the database. Thus, a gapless assignment of unique keys is ensured.
• Late numbering is available for managed and unmanaged implementation scenarios with and without draft. ref blog

When does dose validation trigger in Managed and Unmanaged Scenarios in RAP?

Managed Scenario – In Managed Scenario, the final check of all involved BOs is done via validations. Validations are called during CHECK_BEFORE_SAVE method. But check_before_save method is not visible in the Managed Scenario.

Unmanaged Scenario – In Unmanaged Scenario, the final check for all involved BOs is done in CHECK_BEFORE_SAVE method. A validation is automatically invoked by the RAP framework if the trigger condition of the Validation is fulfilled( CREATE, UPDATE, DELETE ). Validations have two parameters – FAILED and REPORTED. Validation is implemented in both Managed and Unmanaged, but in Unmanaged, it can be implemented only if it has DRAFT capability in RAP BO.

In the DRAFT scenario, we have a special action ‘PREPARE’ which calls Determination and Validation. Syntax to write in BDEF is – Draft Determine Action PREPARE.

When does dose Determination trigger in Managed and Unmanaged Scenarios in RAP?

Determination can be created in two types: on Save and on Modify
on Save – On Save determination will trigger at the time of save. When we need to calculate/update the value of any field and show the updated value on the frontend after the actual save.
on Modify – On Modify, determination will trigger before save. When we need to calculate/update the value of any field and show the updated value on the frontend before the actual save.

DETERMINATION Trigger Condition
Create , Update, Delete, Field(Change of Mentioned Field)

Draft determine action Prepare { }- whenever we create Determination or validation using ‘on SAVE’ method, we need to call it inside Method’ Draft determine action Prepare { }’ . other wise it will not trigger.

When we write determination on modify, we don’t need to trigger it inside ‘Draft determine action Prepare{ } ‘.
There is one issue with determining on Modify . The value of the edited field is not updated as soon as we press Enter on UI. To update this value, we need to write SIDE EFFECT.

eg – side effect {field Course affects field Courseduration; }

What is the significance of CHECK_BEFORE_SAVE?

Managed Scenario – Validations are called during the CHECK_BEFORE_SAVE method. Unmanaged Scenario – Validations are called during the CHECK_BEFORE_SAVE method with FAILED and REPORTED parameters. The CHECK_BEFORE_SAVE method is called during the SAVE sequence. If the method returns error in FAILED parameter, SAVE sequence is terminated and CLEANUP_FINALIZE method is called.

What is Draft Determine Action PREPARE?

Execute the Determination and Validation in the behaviour definition.
The PREPARE action enables validating only Draft data(before it becomes active data).
PREPARE Action ensures data consistency before going to the SAVE method.
In the Unmanaged Scenario, Determination and Validations are called only inside the PREPARE action.

What is CDS Abstract Entity in RAP?

In the Context of RAP, Abstract Entities are used as parameters of RAP actions, RAP functions, and RAP business events. eg- to create pop up in RAP. Abstract entities are non-SQL CDS entities. It is not created as a database object, hence client handling is not defined. A CDS abstract entity can be used as a global structured type in an ABAP programme.

@EndUserText.label: 'leased mass update'
define abstract entity zd_som_leased_mass
{
  @EndUserText.label: 'Duration'
  @ObjectModel.mandatory: true
  Duration    : zsom_duration;
  @EndUserText.label: 'Price'
  @ObjectModel.mandatory: true
  Price       : zsom_output_value;
}