The CDS view name is the ABAP-level name used within the ABAP environment. It’s the name you use to reference the CDS view in ABAP programs, in other CDS views, or in tools like ADT (Eclipse). It represents the semantic model and is part of the ABAP repository.

On the other hand, @AbapCatalog.sqlViewName defines the technical name of the SQL view that gets created in the underlying database when you activate the CDS view. This SQL view acts as a bridge between the ABAP dictionary and the actual database. The SQL view is stored in the database and can be accessed using standard SQL statements if needed.

In simple terms:

• The CDS view name = used in the ABAP layer (semantic name for CDS).

• The sqlViewName = used in the database layer (technical name for DB view).

For example:

@AbapCatalog.sqlViewName: ‘ZEMP_SQL’
@EndUserText.label: ‘Employee CDS View’
define view ZCDS_Employee as select from zemployee {
key emp_id,
emp_name,
emp_dept
}

Here, ZCDS_Employee is the CDS view name (used in ABAP), while ZEMP_SQL is the SQL view name (created in the database).

Key Differences Summary

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

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.

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

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

• ABAP’s database-independent SQL.
• Works on all supported DBs (HANA, Oracle, MSSQL, DB2, …).
• ABAP converts Open SQL statements into the database-specific SQL automatically.
• Ensures portability → same ABAP program runs regardless of underlying DB.
• Supports buffering (e.g., table buffers in SAP).

• Only a subset of SQL is allowed (the part SAP makes portable).

Example :

DATA: it_mara TYPE TABLE OF mara.

SELECT matnr mtart FROM mara
INTO TABLE it_mara
WHERE mtart = ‘FERT’.

• This works in any DB under SAP (Oracle, HANA, DB2, etc.).

• Optimized by SAP kernel, can use table buffering.

2. Native SQL

• Database-specific SQL.

• You write SQL directly for the underlying DBMS.

• Executed via EXEC SQL … ENDEXEC or ADBC (ABAP Database Connectivity).

• No automatic portability → may not work if you change DB.

• No table buffering → always hits the DB.

• Useful when:

  • You need features not available in Open SQL (e.g., DB-specific functions, hints).

  • You want DB-level optimizations.

Example:

DATA: lv_matnr TYPE mara-matnr.

EXEC SQL.
SELECT MATNR INTO :lv_matnr
FROM MARA
WHERE MTART = ‘FERT’
ENDEXEC.

This will only work if the DB syntax matches your system (e.g., Oracle-specific SQL won’t run on HANA).

Key Difference Summary:

They act as a semantic layer that simplifies data consumption, allowing RAP BOs to work with ready-to-use data models that follow SAP extensibility rules.

Example : Join Sales Order Header and Item

• Business Requirement: A key user wants to see Sales Order header information along with Item details in a single service.

• Custom CDS View:

  • Data Source 1 → I_SalesOrder (standard CDS for sales order header)

  • Data Source 2 → I_SalesOrderItem (standard CDS for items)

  • Join Condition → SalesOrder = SalesOrder

  • Fields Selected → SalesOrderID, SalesOrderDate, CustomerID, ProductID, Quantity

• Usage in RAP: This Custom CDS View can be exposed as an OData API in RAP, and consumed in a Fiori Elements app for Sales Order analysis.

Steps to Create Search help Using CDS View.

Step1 : create a CDS view

Step 2 : GOTO SE11 –> Search Help In selection method add the CDS view SQL view name.

Step 3 : Append it in the collective search Refer to the Append structure to add the elementary search in collective.

Test:

Step 4 : In the collective search after append the structure we can call it in the program

We have successfully created A search Help using CDS View.