CDS Table Functions
RAP / CDS / ODataadvanced

CDS Table Functions Part 5: Testing, Clean Core and Alternatives

Key takeaway

Keep table functions maintainable: test them with ABAP Unit and test doubles, protect them with access control on the wrapping view, respect ABAP Cloud rules for AMDP, and know the modern alternatives in CDS.

Explanation

📌 KEY POINTS
✅ Test table functions with ABAP Unit using test doubles for the tables they read.

✅ Put access control (DCL) on the wrapping CDS view entity that consumers use.

✅ In ABAP Cloud, AMDP may only access own objects and SAP objects released for AMDP (C4).

💡 Re-check alternatives regularly — newer CDS releases may make the table function unnecessary.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE

Parts 1–4 built a correct and fast table function. This part keeps it safe and maintainable.

━━━━━━━━━━━━━━━━━━━━
▶ 1. TESTING

  • Unit tests with the CDS Test Double Framework (cl_cds_test_environment) for the wrapping view, and test doubles for the database tables used by the AMDP (depending on your release, the framework can double the dependencies of table functions).
  • Insert controlled test data (two suppliers, several dates, two clients if relevant) and assert: ranking, day counts, client isolation, parameter filtering.
  • Also test edge cases: no data, equal dates (ranking ties), boundary dates.
  • Run tests in ATC / transport checks.

━━━━━━━━━━━━━━━━━━━━
▶ 2. ACCESS CONTROL

  • Table functions themselves typically have no DCL role; consumers should read the wrapping view entity, which gets @AccessControl.authorizationCheck: #CHECK and a DCL role (CDS Views Part 4).
  • Do not let consumers bypass the wrapper — document that the function is internal.

━━━━━━━━━━━━━━━━━━━━
▶ 3. ABAP CLOUD AND CLEAN CORE

  • AMDP is available in ABAP for Cloud Development with restrictions: the USING clause may reference only your own objects and SAP objects released with contract C4 (use in AMDP).
  • SAP tables are not C4-released — read your own tables or C4-released views.
  • On-premise Standard ABAP allows more, but clean-core rules recommend the same restriction.

━━━━━━━━━━━━━━━━━━━━
▶ 4. ALTERNATIVES TO CHECK

  • CDS view entity features: CASE, aggregations, date functions, UNION, parameters.
  • CDS hierarchies for parent-child structures.
  • Analytical queries (define transient view entity / analytical projection, depending on release) for ranking and top-N in analytics.
  • Virtual elements (ABAP code after read) for small per-row calculations in RAP queries.
  • RAP unmanaged queries (custom entities) when logic must run in ABAP, e.g. calling APIs.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DOCUMENTATION

Header comment in the class: purpose, why CDS was insufficient, parameters, client handling, performance measurements, tests. This saves reviewers hours.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

  1. Create a test class for the wrapping view with test doubles.
  2. Cover ranking, client isolation, parameters and edge cases.
  3. Add DCL to the wrapper.
  4. Check the USING list against ABAP Cloud rules.
  5. Review whether a CDS feature now replaces the function.

✅ CHECKPOINT: your table function is tested, secured and justified. Next topic: AMDP in depth.

Code example

ABAP Code
" ===== ABAP Unit test for the wrapping view with test doubles =====CLASS ltc_aging_rank DEFINITION FINAL FOR TESTING  DURATION SHORT RISK LEVEL HARMLESS.  PRIVATE SECTION.    CLASS-DATA environment TYPE REF TO if_cds_test_environment.    CLASS-METHODS class_setup.    CLASS-METHODS class_teardown.    METHODS setup.    METHODS ranks_oldest_first FOR TESTING.ENDCLASS. CLASS ltc_aging_rank IMPLEMENTATION.  METHOD class_setup.    " doubles the dependencies of the view under test (incl. the table function's    " sources where supported by your release)    environment = cl_cds_test_environment=>create( i_for_entity = 'ZI_PURCHREQAGINGTOP3' ).  ENDMETHOD.   METHOD setup.    environment->clear_doubles( ).    DATA heads TYPE STANDARD TABLE OF zpr_head WITH EMPTY KEY.    heads = VALUE #(      ( request_id = '0000000001' supplier = 'S1' status = 'S' created_on = '20260901' )      ( request_id = '0000000002' supplier = 'S1' status = 'S' created_on = '20260801' )      ( request_id = '0000000003' supplier = 'S2' status = 'S' created_on = '20260915' ) ).    environment->insert_test_data( i_data = heads ).  ENDMETHOD.   METHOD ranks_oldest_first.    SELECT RequestID, AgeRank      FROM zi_purchreqagingtop3( p_keydate = '20260930' )      WHERE Supplier = 'S1'      ORDER BY AgeRank      INTO TABLE @DATA(result).     cl_abap_unit_assert=>assert_equals( act = result[ 1 ]-RequestID exp = '0000000002' ).    cl_abap_unit_assert=>assert_equals( act = lines( result ) exp = 2 ).  ENDMETHOD.   METHOD class_teardown.    environment->destroy( ).  ENDMETHOD.ENDCLASS. // ===== Access control on the WRAPPER (consumers use this) =====// @AccessControl.authorizationCheck: #CHECK// define view entity ZI_PurchReqAgingTop3 ...   + DCL role filtering by company code " ===== ABAP Cloud: USING list only own objects or C4-released SAP objects =====" USING zpr_head            -> own table: OK" USING ekko                -> SAP table, not C4: not allowed

Real project scenario

A table function behind a supplier dashboard had no tests. A developer "optimized" the ranking and accidentally changed ORDER BY created_on to ORDER BY request_id; the dashboard silently showed the wrong "oldest" requests for weeks.
The team added ABAP Unit tests with test doubles for ranking, client isolation and parameters, and ran them in the transport check. When a later release made a CDS-native alternative possible for part of the logic, the tests allowed them to replace the SQLScript with confidence.

Common mistakes

  • No automated tests for SQLScript logic.
  • Consumers reading the table function directly without access control.
  • Using SAP tables in USING in ABAP Cloud.
  • Not testing client isolation and ranking ties.
  • Never re-evaluating CDS alternatives.
  • No documentation of why the function exists.

Best practices

  • Test via the wrapping view with the CDS Test Double Framework.
  • Secure the wrapper with DCL; treat the function as internal.
  • Restrict USING to own or C4-released objects.
  • Document purpose, parameters, client handling and measurements.
  • Review regularly whether CDS features can replace the function.

Interview angle

Questions: "How do you test a CDS table function?", "How is authorization handled?", "Can you use AMDP in ABAP Cloud?"
Strong answer: test through the wrapping view with the CDS Test Double Framework and ABAP Unit, doubling source tables and covering ranking, client isolation, parameters and edge cases; secure the wrapping view with DCL and keep the function internal; in ABAP Cloud AMDP may access only own objects and SAP objects released with C4; consider alternatives such as CDS features, hierarchies, analytical queries, virtual elements or custom entities.

Practice this lesson

Quick check

1. How should consumers such as a RAP service access a CDS table function?

2. In ABAP Cloud, which object may appear in the USING clause of a table function implementation?

3. What is the primary purpose of defining a CDS table function in an SAP RAP/CDS scenario?

Interview questions

1. How do you test and secure a CDS table function?

Answer it in your own words first, then compare.

2. You inherit several CDS table functions. What do you review?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics