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:
Best Use Cases:
-
Cross-schema data access
-
Complex calculations requiring loops, conditional logic
-
Data type compatibility issues between joined tables
-
Performance-critical operations requiring database-level processing
Advantages:
-
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
Best Use Cases:
-
Simple field calculations (e.g., bonus calculation, days to flight)
-
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
Performance Comparison
Interchangeability Assessment
When They Can Be Used Interchangeably
Limited scenarios only:
-
Single-field computations where both virtual elements and table functions could work
When They Cannot Be Interchanged
Custom Entity is Unique For:
Table Function is Essential For:
-
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 :)