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.

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!”);
}
});
}

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.

Firstly,

Create an employee table with the draft à zemployee_01

Create a draft table. à zemployee_01_d

Create a class to insert the data. à zdpm_populate_empoyee

Create a CDS root view entity  à zdpm_employee_transapp

Create a projection, View. à zcl_employee_trans.

Now create a metadata extension with UI annotation à zdpm_employee_transapp

Create managed implementation on CUD operations.

Behavior Definition.

Make the class using the code below à zdp_i_employee_transapp

Create a local classà lcl_

Create a business projection for business object. à zc_employee_transapp

Create a service definition.

Choose the defined service.

Use the projection view name

Now create the service binding

If the service is not getting published, then change it to OData V2- UI.

Now publish it, you will get the entity set then login to the Fiori application.

Goto the service URL.

Login in and click on the GO to view the data.

Now click on the row and you will find the detailed information.

You can add the filer based on the fields like:

Completed.

It is exposed via a behavior definition and then published as an OData/Web API service.

1. Create a Custom Entity in CDS

@EndUserText.label: ‘Custom Employee API Entity’
define custom entity ZC_EMPLOYEE_API {
key empid : abap.char(10);
empname : abap.char(40);
department: abap.char(20);
}

2. Define a Behavior Implementation (Handler Class)

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

CLASS zcl_employee_handler IMPLEMENTATION.
METHOD if_rap_query_provider~select.
DATA lt_data TYPE TABLE OF zc_employee_api.

“Fetch data (from table, FM, RFC, etc.)
SELECT empid, empname, dept AS department
FROM zemployees
INTO TABLE @lt_data.

“Return data
result = CORRESPONDING #( lt_data ).
ENDMETHOD.
ENDCLASS.

3. Register Service in Service Definition

@EndUserText.label: ‘Employee API Service’
define service ZUI_EMPLOYEE_API {
expose ZC_EMPLOYEE_API;
}

4. Publish via Service Binding

• Create a Service Binding (ZUI_EMPLOYEE_API_BIND).
• Choose OData V4 as binding type.
• Activate it → SAP generates a URL endpoint.

/sap/opu/odata4/sap/zui_employee_api/srvd_a2x/sap/zui_employee_api/0001/

5. Test the API

• Use /IWFND/MAINT_SERVICE (for OData V2 in SEGW) or Fiori Preview (for OData V4).

• Run the URL in browser or Postman:

GET …/ZC_EMPLOYEE_API

Summary

• Custom Entity = Virtual CDS entity (no table).

• Implement a handler class to supply data.

• Expose it in a service definition.

• Bind it with service binding (OData V2/V4).

• Test via Fiori preview or Postman.

It is a utility class that provides a static method get_client_proxy to connect to the external OData V2 service API_PRODUCT_SRV via the BTP cloud destination iaapinc.
The method:

• Reads the cloud destination,
• Creates an HTTP client,
• Builds an OData V2 proxy (/iwbep/if_cp_client_proxy) based on proxy model /IAP/CHM_SCM_PRODUCT,
• Returns this proxy so other classes can easily consume the Product API without handling low-level HTTP setup.

👉 In short: It’s a helper to simplify access to the Product OData API in SAP BTP ABAP.