Core Data Services (CDS) Views: Deep Dive and Best Practices

CDS Views

In the modern SAP landscape, particularly with SAP S/4HANA and the SAP Business Technology Platform (BTP), Core Data Services (CDS) Views have become the bedrock of data modeling and consumption. Far beyond traditional database views, CDS views offer a powerful, semantically rich, and database-agnostic approach to defining, exposing, and consuming data.

This comprehensive guide will take you on a deep dive into CDS views, exploring their capabilities, different types, and crucially, the best practices to ensure optimal performance, maintainability, and reusability in your SAP development projects.

What are Core Data Services (CDS) Views? A Paradigm Shift

At its heart, CDS is a declarative data modeling infrastructure for defining and consuming SAP data models. It’s a fundamental part of the SAP HANA platform and is tightly integrated with the ABAP platform (ABAP CDS). Unlike traditional ABAP Dictionary views which primarily focus on creating SQL views on the database, CDS views:

• Operate at the Application Server Level (ABAP CDS): They are defined and managed within the ABAP layer, making them portable and reusable across different database systems (though highly optimized for SAP HANA).
• Embrace Code-to-Data Paradigm: They push complex logic and calculations down to the database layer, leveraging SAP HANA’s in-memory capabilities for significant performance gains.
• Semantically Rich: Through annotations, CDS views embed metadata that enriches the data model with business semantics, UI properties, analytical functionalities, and authorization information. This makes them self-describing and easier for consuming applications (like SAP Fiori) to understand and utilize.
• Service-Enabled: They are the foundation for exposing business data as OData services (especially in the ABAP RESTful Application Programming Model – RAP), simplifying API development and integration.

The Evolution: From ABAP Dictionary Views to CDS

While ABAP Dictionary views still exist, CDS views represent a significant evolution:

Types of CDS Views: Building the Virtual Data Model (VDM)

A structured approach to CDS view development often follows the Virtual Data Model (VDM) concept, which layers views to promote reusability and maintainability.

1. Basic Views (Interface Views):
   • Purpose: Expose raw data directly from database tables, often adding basic semantics and associations. They form the foundational layer of the VDM.
   • Characteristics: Simple projections, minimal calculations, often contain key fields and essential attributes.
   • Annotation: @VDM.viewType: #BASIC (or #BASIC)
   • Usage: Internal consumption by other CDS views (Composite or Consumption views), not typically exposed directly to the UI.
2. Composite Views (Interface Views):
   • Purpose: Combine multiple Basic views or other Composite views using associations and joins. They represent more complex business entities or aggregated data.
   • Characteristics: Contain business logic, aggregations, calculations, and more complex associations.
   • Annotation: @VDM.viewType: #COMPOSITE (or #COMPOSITE)
   • Usage: Provide a consolidated data source for Consumption views or other Composite views. They are still part of the “interface” layer.
3. Consumption Views:
   • Purpose: Tailored for specific application requirements, often designed for direct consumption by UI applications (like SAP Fiori apps using Fiori elements) or analytical tools.
   • Characteristics: Select specific fields from Composite views, apply UI-specific annotations (@UI.lineItem, @UI.fieldGroup, etc.), and might include parameters for filtering.
   • Annotation: @VDM.viewType: #CONSUMPTION (or #CONSUMPTION)
   • Usage: The topmost layer of the VDM, directly consumed by external applications.
4. Custom Entities (Virtual CDS Views):
   • Purpose: Used when data cannot be retrieved purely via SQL, for instance, when data needs to be fetched from external APIs, legacy BAPIs, or requires complex ABAP logic that cannot be pushed down to the database.
   • Characteristics: Defined with DEFINE CUSTOM ENTITY. The data retrieval logic is implemented in an ABAP class.
   • Usage: Integral to unmanaged scenarios in ABAP RAP, providing a bridge between CDS and custom ABAP logic.
5. CDS Table Functions:
   • Purpose: Similar to custom entities, but the underlying implementation is an ABAP Managed Database Procedure (AMDP) or native SQLScript. This allows for highly optimized, database-specific logic.
   • Characteristics: Defined with DEFINE TABLE FUNCTION.
   • Usage: For scenarios requiring maximum performance by leveraging native HANA features, often used in complex analytical scenarios.

Key Features and Capabilities

• Associations: Define relationships between CDS entities (like foreign key relationships but more powerful). They eliminate the need for explicit JOIN conditions in consuming views and enable “path expressions” for traversing relationships efficiently.
• Annotations: The heart of CDS. These are metadata tags that enrich the data model with semantic information. Examples include:
  • @Analytics.query: true: Marks a view as an analytical query.
  • @UI.lineItem: Defines a field’s appearance in a Fiori List Report.
  • @Semantics.amount.currencyCode: Specifies a currency code for an amount field.
  • @AccessControl.authorizationCheck: #CHECK: Activates ABAP authorization checks.
• Parameters: Allow dynamic input values to filter or modify the result set of a CDS view.
• Expressions and Functions: Support for SQL functions (e.g., SUM, COUNT, MAX, MIN, CONCAT), case statements, and calculations directly within the view definition, pushing processing to the database.
• Extensibility (EXTEND VIEW): Allows customers or partners to add fields, associations, or enhance logic to standard SAP CDS views without modifying the original object. This is crucial for clean core development.
• Client Handling: CDS views inherently handle client-dependent data, ensuring that users only see data relevant to their logon client.
• Currency/Quantity Conversion: Built-in capabilities via annotations and specific functions to handle unit and currency conversions.

Best Practices for CDS View Development

Developing robust and performant CDS views requires adherence to certain best practices:

1. Follow the VDM Layering (Basic, Composite, Consumption):
   • Reusability: Promotes reuse of basic data models.
   • Modularity: Breaks down complexity into manageable layers.
   • Maintainability: Easier to locate and fix issues.
   • Performance: Enables the database optimizer to prune unnecessary data or joins based on the requested consumption layer.
   • Rule: Consumption views should only consume other Interface views (Basic or Composite), not directly physical tables.
2. Optimize Performance:
   • Minimize Fields: Only project the fields absolutely necessary in each view, especially in consumption layers.
   • Push Down Filters and Aggregations: Ensure filters are applied as early as possible (at the lowest possible view level) to reduce the data volume processed. The HANA optimizer is good at this, but explicit design helps.
   • Use Associations Wisely: Leverage associations over explicit JOIN clauses. Associations are lazy-loaded, meaning the JOIN only occurs if the associated data is actually requested via a path expression.
   • Careful with UNION and LEFT OUTER JOIN: While powerful, these can impact performance if not used judiciously. Be precise with cardinality in outer joins (e.g., [0..1], [1..1]).
   • Avoid Complex Calculations on Large Datasets: If a calculation is very complex and applies to a huge dataset, consider if it can be broken down or applied after initial filtering/aggregation.
   • Monitor with Tools: Use ADT’s “Dependency Analyzer” and “SQL Analysis” tools to understand view complexity and generated SQL, and use HANA PlanViz for detailed performance analysis.
3. Naming Conventions:
   • Adopt consistent naming conventions for CDS views (e.g., I_ for interface, C_ for consumption, P_ for projection in RAP), fields, associations, and parameters. This improves readability and collaboration.
   • Example: I_Product, C_SalesOrderReport, _ProductText (for association).
4. Annotations are Key:
   • Use Relevant Annotations: Apply appropriate annotations for semantics, UI, analytics, and authorization to make your views self-describing and consumable by frameworks.
   • Avoid Over-Annotation: Don’t add annotations if they aren’t providing meaningful metadata or are not used by consuming applications.
   • Separate Concerns: While some annotations are at the interface level, UI-specific annotations should primarily reside in the Consumption views.
5. Authorization and Security:
   • Access Control (DCL): Always define a Data Control Language (DCL) for your CDS views to enforce read-level authorizations based on ABAP authorization objects. This ensures data security.
   • @AccessControl.authorizationCheck: #CHECK: Actively enable authorization checks on your views.
6. Extensibility by Design:
   • When designing custom CDS views that might be extended by others, ensure they are enabled for extensibility using annotations like @AbapCatalog.extensibility.extensible: true.
7. Testing:
   • Write ABAP Unit Tests for custom logic within your CDS views (e.g., when using virtual elements or CDS table functions).
   • Use the “Data Preview” feature in ADT extensively to validate the data returned by your views.
8. Avoid Anti-Patterns:
   • Deeply Nested Views: While layering is good, too many layers of views can lead to complexity and potential performance issues. Keep the stack depth reasonable.
   • Direct Table Access in Consumption Views: Avoid SELECT FROM physical tables directly in consumption views. Always build upon interface views.
   • Rebuilding ABAP Logic: Don’t try to replicate complex imperative ABAP logic directly within CDS view expressions if it leads to convoluted or unmaintainable code. For highly complex logic, consider CDS table functions (AMDP) or custom entities.

The Future of Data Modeling with CDS

CDS views are not just a temporary technology; they are the strategic foundation for data modeling in SAP’s future:

• Integral to ABAP RAP: The ABAP RESTful Application Programming Model (RAP) relies entirely on CDS views for data modeling, transactional behavior, and service exposure.
• Foundation for S/4HANA: All new data models and extensions in S/4HANA (both Cloud and On-Premise) leverage CDS views.
• Enabler for Intelligent Enterprise: CDS views provide the semantic richness required for advanced analytics, machine learning, and intelligent applications.

Conclusion

Core Data Services (CDS) views are an indispensable part of modern SAP development. By deeply understanding their capabilities, adhering to best practices, and strategically applying them in your projects, you can build performant, flexible, and future-proof data models. Embrace the power of CDS, and unlock the full potential of your SAP S/4HANA and BTP applications.