Custom Entity vs. Table Function vs. Virtual Elements in SAP RAP

Custom Entity vs. Table Function vs. Virtual Elements in SAP RAP

SAP RAP

These three CDS approaches - Custom Entity, Table Function (with AMDP), and Virtual Elements - each serve distinct purposes and are not fully interchangeable. While they all enable custom logic in CDS models, their architectural differences make them suitable for specific use cases.

Let's explore them one by one.

Key Differences and Use Cases

Custom Entity

Purpose: For complex data sources that cannot be represented by standard database tables.

Architecture:

  • Implemented entirely in ABAP classes using IF_RAP_QUERY_PROVIDER interface

  • Executes on the application server

  • No direct database SELECT statement - data is fetched programmaticall

Best Use Cases:

  • External data sources (RFC calls, web services, APIs)

  • Complex business logic requiring ABAP processing

  • Data from dynamically generated tables (e.g., FICA BIT classes)

  • Multiple result sets or complex data transformation

  • Non-persistent data that changes frequentl

Limitations:

  • Performance overhead - all logic runs on application serve

  • Manual implementation of paging, sorting, filterin

  • Limited association capabilities with standard CDS entitie


Table Function (AMDP)

Purpose: Complex database-level calculations and operations that cannot be achieved with standard CDS syntax.

Architecture:

  • Implemented using AMDP (ABAP Managed Database Procedures)

  • Executes on the database layer using SQLScript

  • Returns tabular data that can be consumed by CDS entities

Best Use Cases:

  • Cross-schema data access

  • Database-specific functions not available in Open SQL

  • Complex calculations requiring loops, conditional logic

  • Data type compatibility issues between joined tables

  • Performance-critical operations requiring database-level processing

Advantages:

  • Superior performance - executes at database level

  • Supports complex SQLScript features

  • Can be consumed like regular CDS entities


Virtual Elements

Purpose: Adding calculated fields to existing CDS entities without database persistence.

Architecture:

  • Defined in CDS projection views with annotations

  • Calculation logic implemented in ABAP classes

  • Executes on application server during runtime

Best Use Cases:

  • Simple field calculations (e.g., bonus calculation, days to flight)

  • Transient fields not requiring persistence

  • Business logic that needs ABAP resources (function modules, BAPIs)

  • Adding computed fields to existing data model

Limitations:

  • Performance impact - breaks code pushdown principle

  • Should be avoided for performance-critical scenarios

  • Limited to single field calculations


Performance Comparison

Approach Execution Location Performance Code Pushdown
Custom Entity Application Server Slowest No
Table Function Database Layer Fastest Yes
Virtual Elements Application Server Slow No

Interchangeability Assessment

When They Can Be Used Interchangeably

Limited scenarios only:

  • Simple calculations that don't require high performance

  • Single-field computations where both virtual elements and table functions could work

  • Small data volumes where performance is not critical

When They Cannot Be Interchanged

Custom Entity is Unique For:

  • External system integration

  • Non-database data sources

  • Complex multi-step business processes

Table Function is Essential For:

  • Database-specific features

  • Cross-schema access

  • High-performance requirement

  • Complex database operation

Virtual Elements Are Specific To:

  • Adding fields to existing CDS projection view

  • Runtime calculations on persisted data

  • Integration with RAP-based applications


Best Practice Recommendations

Performance-Critical Scenarios: Use Table Functions with AMDP for database-level processing.

External Data Integration: Use Custom Entities when standard database access is insufficient.

Simple Field Calculations: Use Virtual Elements sparingly and only for non-performance-critical scenarios.

Complex Business Logic: Choose based on data source - Custom Entity for external data, Table Function for database operations.

In conclusion, while these three approaches may overlap in some basic scenarios, they are designed for different architectural patterns and cannot be used interchangeably for all requirements. The choice depends on your specific data source, performance requirements, and integration need.

Thanks for reading :)