Next, you create an ABAP class (the query provider class) that implements the interface IF_RAP_QUERY_PROVIDER. The core method IF_RAP_QUERY_PROVIDER~SELECT must be redefined in this class. Inside this method, you write custom ABAP logic to retrieve data — it could be from a database table, an API, or even a legacy system. You then fill the result table and pass it back to the framework.

This unmanaged approach is used when data retrieval cannot be handled by CDS-based managed queries (for example, reading from custom logic, calling RFCs, or combining different data sources). It provides greater flexibility at the cost of additional coding responsibility.

Example structure:

CLASS zcl_query_provider DEFINITION
PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES if_rap_query_provider.
ENDCLASS.

CLASS zcl_query_provider IMPLEMENTATION.
METHOD if_rap_query_provider~select.
” Custom data retrieval logic
ENDMETHOD.
ENDCLASS.

In such cases, you define a Query Behavior Definition (behavior definition for a query) and then implement it manually using an Unmanaged Query Implementation Class. This class must implement the interface IF_RAP_QUERY_PROVIDER, particularly the method IF_RAP_QUERY_PROVIDER~SELECT, which contains the ABAP logic to fetch and return data. This approach gives full control over query execution, filtering, and pagination. It’s typically used in integration scenarios or custom reports where CDS-based managed queries are insufficient.

DCLs are written using the DEFINE ROLE syntax and stored as authorization objects in the ABAP Dictionary.
They work in combination with authorization checks performed automatically at runtime by the ABAP system — when the CDS view is queried through ABAP, OData, or analytical tools.

Purpose of DCL

• To control access to data at the CDS view level (not in ABAP code).

• To ensure data security and compliance with organizational policies.

• To centralize authorization logic so it’s reusable and not hardcoded in multiple reports or services.

In simple terms:

DCL defines who can access what data in a CDS view.

How DCL Works

1. A CDS view is defined with an authorization check annotation:

   @AccessControl.authorizationCheck: #CHECK
   define view ZCDS_Employee as select from zemployee { … }

   2. A DCL (authorization rule) is created using DEFINE ROLE.

   It specifies the conditions under which a user can access the data At runtime, when a user executes the CDS view (via report, OData, or Fiori app),
   the system automatically filters data according to the DCL rule.

PFCG Authorization Object Link

The function aspect pfcg_auth('AUTH_OBJECT', 'FIELD') links the DCL to a PFCG (Profile Generator) authorization object.
This ensures integration between CDS-level security and SAP’s standard role-based security.

Example authorization object definition:

• Authorization object: ZEMP_AUTH_OBJ

• Field: DEPT

• Values assigned in user role (e.g., user only has DEPT = ‘HR’)

Then when user runs the view:

• They will only see rows where department = 'HR'.

1. In ABAP Development Tools (ADT):

   • Go to File → New → ABAP Project.

   • Connect to your system.

   • Create a new ABAP Package (e.g., Z_RAP_BUTTONS).

2. Create the RAP artifacts:

   • Business Object (BO):

     • Right-click the package → New → Other ABAP Repository Object → Business Object → RAP Business Object.

     • Example: ZBO_SALESORDER.

Step 2: Define the Behavior (Behavior Definition)

1. In your Behavior Definition (.behavior):

define behavior for ZI_SALESORDER
persistent table ZI_SALESORDER
lock master
{
create;
update;
delete;

// Add custom action button
action confirm order result [0..1];
}

Step 3: Implement the Behavior Logic

1. In Behavior Implementation (.behavior.abap):

implementation in class zbp_i_salesorder unique;

method confirm_order.
” Your business logic goes here
loop at it_entity into data(ls_entity).
ls_entity-status = ‘CONFIRMED’.
modify table et_entity from ls_entity.
endloop.
endmethod.

endimplementation.

Step 4: Expose Action in Service Definition

1. Open Service Definition (.service):

define service ZC_SALESORDER_SRV {
expose ZI_SALESORDER;
// Optionally expose action explicitly
action confirm order;
}

Step 5: Register & Test Service

1. Go to /IWFND/MAINT_SERVICE → register your RAP service.

2. Test via SAP Gateway Client (/IWFND/GW_CLIENT) to see the metadata:

   • You should see your confirm order action exposed.

Step 6: Fiori/UI Integration

• If you use Fiori Elements (List Report / Object Page):

  1. The action confirm order will automatically appear as a button in the Object Page or List Report.

  2. No extra UI5 code is required if you use standard Fiori Elements.

  3. If you want custom UI5, you can bind a button like this:

<Button
text=”Confirm Order”
press=”.onConfirmOrder”
/>

And in your controller:

onConfirmOrder: function(oEvent) {
var oModel = this.getView().getModel();
var sPath = oEvent.getSource().getBindingContext().getPath();
oModel.callFunction(“/ConfirmOrder”, {
method: “POST”,
urlParameters: {
SalesOrderID: oModel.getProperty(sPath + “/SalesOrderID”)
},
success: function() {
MessageToast.show(“Order Confirmed!”);
},
error: function() {
MessageToast.show(“Error!”);
}
});
}

custom Entity:

@EndUserText.label: ‘template Download’

@ObjectModel: {

query: {

implementedBy: ‘ABAP: ZCL_DOWN_TEMPLATE’

}

}

define root custom entity ZCHM__TMP_DWN

{

key docnum : abap.char(10);

comp_code : abap.char(4);

sales_org : abap.char(4);

distr_chn : abap.char(2);

division : abap.char(2);

ref_doc : abap.char(20);

currency : abap.char(8);

ref_item : abap.char(10);

material : abap.char(40);

matl_group : abap.char(9);

net_amount : abap.char(40);

gross : abap.char(15);

quantity : abap.char(13);

price_unit : abap.char(5);

bill_unit : abap.char(3);

file_content : abap.string( 999999999 );

}

then Create a Class where you can write you logic to create the template and pass the file content to the front end.

Now activate the class and expose it the service definition and at last create a web API v4 and pass the URL to the front person to fetch and download the excel sheet.

HIDE → to store values “hidden” behind a line for later retrieval.

USER COMMAND (AT USER-COMMAND) → to react to user actions (e.g., double-clicks, buttons, PF keys).

1. GET CURSOR

This is used to know where the user placed the cursor or clicked in a list.

GET CURSOR FIELD gv_field VALUE gv_value.

• gv_field → variable to hold the field name under the cursor.
• gv_value → variable to hold the value of that field.

Example:

GET CURSOR FIELD lv_field VALUE lv_value.
WRITE: / ‘Cursor on:’, lv_field, ‘Value:’, lv_value.

2. HIDE

The HIDE statement stores the value of a variable in the system’s hide area, linked to the current line.
Later, when the user double-clicks on that line, the hidden values are retrieved automatically.

Example:

LOOP AT it_mara INTO wa_mara.
WRITE: / wa_mara-matnr, wa_mara-maktx.
HIDE: wa_mara-matnr, wa_mara-maktx.
ENDLOOP.

When the user double-clicks on a line, the hidden fields for that line become available again.

3. USER COMMAND (AT USER-COMMAND)

This event block reacts to user actions (function keys, buttons, or double-clicks).

Example:

AT USER-COMMAND.
CASE sy-ucomm.
WHEN ‘DETAIL’. “Custom function code
WRITE: / ‘Details for material:’, wa_mara-matnr.
WHEN ‘EXIT’.
LEAVE PROGRAM.
ENDCASE.

Full Example:

REPORT zsample_report.

TABLES: mara.

DATA: wa_mara TYPE mara.

START-OF-SELECTION.
SELECT * FROM mara UP TO 10 ROWS.
WRITE: / mara-matnr, mara-mtart, mara-mbrsh.
HIDE: mara-matnr.
ENDSELECT.

AT LINE-SELECTION. “Triggered by double-click
WRITE: / ‘You selected material:’, mara-matnr.

AT USER-COMMAND.
CASE sy-ucomm.
WHEN ‘DETAIL’.
GET CURSOR FIELD DATA(lv_field) VALUE DATA(lv_value).
WRITE: / ‘Field:’, lv_field, ‘Value:’, lv_value.
WHEN ‘EXIT’.
LEAVE PROGRAM.
ENDCASE.

Key Components of the Managed Save Sequence

•  Standard Behavior
  • Automatically saves changes made to entity instances in the database.
  • Ensures consistent data persistence without requiring additional coding.
• Steps in the Sequence
  • Data Validation: Validates the modified instance to ensure data integrity.
  • Data Modification: Updates or inserts the instance data into the database.
  • Lifecycle Management: Manages the lifecycle events triggered during the save process.
  • Post-Save Actions: Completes any final actions after the data persisted.
• Customizing with Extra Save
  • The extra save feature allows adding additional logic to the save process, such as logging changes or triggering external services.
  • Developers can implement additional steps using the save_modified method in a saver class.
•  Change Tracking
  • Logs changes made to an instance, such as modified fields or newly added data.
  • These changes can be written to a log table for auditing or debugging purposes.

Unmanaged save is ideal when the default save logic in the RAP framework (managed save)cannot handle specific business requirements. It gives developers full control over how data persisted, enabling customization for complex scenarios like:

 Custom Table Structures: When data is stored in unconventional formats or across multiple tables.
 Advanced Integrations: When saving data involves external APIs or systems.
 Complex Logic: For operations requiring extensive calculations, validations, or dependencies between entities.

Steps to implement unmanage save.
Before that ensure persistence, table is not specified, as unmanaged save implementation cannot have persistence table specified to it.

Step 1: Include the unmanaged save keywords for all nodes where unmanaged behavior is required.

Step 2: Redefine method save_modified in Saver Local class implementation level.

In this way we can implement the Unmanaged Save Sequence.

• Search Help (free text search): Implemented via @Search annotations on CDS views.
• Value Help (F4 help / dropdowns): Implemented via associations + @Consumption.valueHelpDefinition annotations.

1. Search Help in RAP

Search is enabled using annotations in the Projection View or Consumption View.

@Search.searchable: true
define view entity ZI_Book
as select from zbook
{
key book_id,
title,
author,
publisher
}

• @Search.searchable: true → Allows free-text search across all fields.
• You can refine it:

@Search.defaultSearchElement: true
title,

@Search.defaultSearchElement: true
author

2. Value Help in RAP

For dropdowns or F4 helps, you define associations and annotate them.

Step 1: Define Value Help View

@EndUserText.label: ‘Value Help for Publishers’
define view entity ZI_PublisherVH
as select from zpublisher
{
key publisher_id,
name
}

Step 2: Add Association in Main View

define view entity ZI_Book
as select from zbook
association [0..1] to ZI_PublisherVH as _Publisher
on $projection.publisher_id = _Publisher.publisher_id
{
key book_id,
title,
publisher_id,
_Publisher
}

Step 3: Annotate Value Help

@Consumption.valueHelpDefinition: [
{ entity: { name: ‘ZI_PublisherVH’, element: ‘publisher_id’ } }
]
publisher_id,

Now in Fiori, publisher_id will show F4 help with dropdown based on ZI_PublisherVH.

It’s similar to SQL but tailored for RAP-managed business objects (like CDS-based BOs).

Common EML Statements

You can use EML to perform:

• READ → retrieve data from BO entities
• CREATE → create new instances
• UPDATE → change existing instances
• DELETE → delete instances
• ACTION → call business actions
• FUNCTION → call determinations/validations indirectly

Syntax Examples

1. Read

READ ENTITIES OF zi_travel
ENTITY travel
FIELDS ( travel_id agency_id status )
WITH VALUE #( ( travel_id = ‘0001’ ) )
RESULT DATA(lt_travel).

2. Create

MODIFY ENTITIES OF zi_travel
ENTITY travel
CREATE
FIELDS ( travel_id agency_id customer_id )
WITH VALUE #( ( travel_id = ‘1001’ agency_id = ‘7000’ customer_id = ‘C01’ ) )
FAILED DATA(ls_failed)
REPORTED DATA(ls_reported).

3. Update

MODIFY ENTITIES OF zi_travel
ENTITY travel
UPDATE
FIELDS ( status )
WITH VALUE #( ( travel_id = ‘1001’ status = ‘X’ ) )
FAILED DATA(ls_failed)
REPORTED DATA(ls_reported).

4. Delete

MODIFY ENTITIES OF zi_travel
ENTITY travel
DELETE
FROM VALUE #( ( travel_id = ‘1001’ ) )
FAILED DATA(ls_failed)
REPORTED DATA(ls_reported).

5. Action Execution

MODIFY ENTITIES OF zi_travel
ENTITY travel
EXECUTE action confirm
FROM VALUE #( ( travel_id = ‘1001’ ) )
FAILED DATA(ls_failed)
REPORTED DATA(ls_reported).

Key Points

• Always executed against business objects (BOs), not database tables.

• Works inside ABAP classes (behavior implementations, service consumption, or test code).

• Returns:

  • RESULT → successful data
  • FAILED → failed instances
  • REPORTED → messages/warnings

•  data types whose type attributes go beyond the regular DDIC structures in the ABAP Dictionary
• prototype definitions of data models without being created as instances of a data object.

Example:
Administrators can update a seller’s email via a “Update Email” button in the Seller Details form.Clicking the button opens a popup modal displaying the current email, an input field for the newemail, and an optional reason for the update. Validation ensures the new email has a proper format and is not duplicated. On save, an abstract entity processes the update, and the system
records the change for compliance.

Create a CDS abstract entity

Add it using action in Behavior definition.

Implement the method and modify the field.

In Preview Screen → Before email update

Email field updated

Conclusion:
Abstract entities in RAP applications provide a powerful framework for enhancing modularity, scalability, and reusability by encapsulating shared business logic and ensuring consistent behavior across root entities. This is particularly evident in scenarios like updating a seller’s email, where an abstract entity centralizes the handling of operations such as validation, transformation, and automated updates. The use of a popup modal for updates, paired with the abstract entity’s logic, ensures a user-friendly experience, streamlined workflows, and systemwide synchronization. This approach aligns with clean architecture principles, resulting in robust, maintainable, and adaptable applications capable of efficiently meeting current and future requirements.