ABAP Cloud Part 3: Replacing Direct Table and Classic API Dependencies
Remediate classic dependencies step by step: inventory tables, function modules, classes and statements used; find released successors; replace table reads with CDS, BAPIs with RAP interfaces or wrappers, and system fields with released classes.
Explanation
📌 KEY POINTS
✅ First inventory every SAP dependency, then find a released successor for each.
✅ Tables → released CDS views; BAPIs/FMs → released RAP BO interfaces or classes; sy fields → released classes.
✅ No successor? → tier 2 wrapper (on-premise/private cloud) or redesign.
⚠️ Check field semantics when switching to CDS — names, units and filters differ from tables.
━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–2 set the goal. Migrating existing code (or porting a design) to ABAP Cloud is mostly dependency remediation. This part gives the method.
━━━━━━━━━━━━━━━━━━━━
▶ 1. INVENTORY
List every SAP object your code touches: tables and views, function modules and BAPIs, classes, BAdIs, transactions called, statements used (WRITE, SUBMIT, CALL TRANSACTION, dynpro). ATC cloud readiness findings (Part 4) produce most of this list automatically.
━━━━━━━━━━━━━━━━━━━━
▶ 2. FIND SUCCESSORS
Sources:
- ADT: the API state of the object, including a successor if SAP defined one ("use I_… instead").
- SAP Business Accelerator Hub: released APIs by product.
- SAP's Cloudification Repository (public list of classic objects and their released successors).
━━━━━━━━━━━━━━━━━━━━
▶ 3. REPLACEMENT PATTERNS
- Table read → released CDS view: VBAK/VBAP → I_SalesOrder/I_SalesOrderItem; LFA1 → I_Supplier; MARA → I_Product.
- Change via BAPI/FM → EML on a released RAP BO interface (…TP) or a released API class.
- sy-uname, sy-datum, sy-uzeit → cl_abap_context_info.
- Number ranges → cl_numberrange_runtime (released).
- Application log → cl_bali_log and related released classes.
- HTTP calls → cl_web_http_client_manager with cl_http_destination_provider.
- Lists/reports → RAP service + Fiori Elements, or console class for technical tools.
- Background processing → application jobs (released job APIs).
━━━━━━━━━━━━━━━━━━━━
▶ 4. SEMANTIC DIFFERENCES
CDS views are not 1:1 copies of tables: names are readable (SalesOrganization instead of VKORG), some filters apply (e.g. only certain document categories), and some fields are calculated. Test with real data and compare results before switching.
━━━━━━━━━━━━━━━━━━━━
▶ 5. NO SUCCESSOR?
- On private cloud/on-premise: a thin tier 2 wrapper released for cloud development (Part 2).
- In public cloud: redesign (other released API, key user extensibility, side-by-side) or raise an influence request with SAP.
━━━━━━━━━━━━━━━━━━━━
▶ 6. MIGRATE IN SMALL STEPS
Replace one dependency at a time, test, then continue. Keep a remediation list with object, old dependency, successor, status.
━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
- Run ATC cloud readiness on the package.
- Group findings by dependency.
- For each dependency, record the successor (ADT, Accelerator Hub, Cloudification Repository).
- Refactor with the patterns in the code example; compare results; re-run ATC.
✅ CHECKPOINT: you can turn a classic program into a list of concrete, testable replacements.
Code example
" ===== BEFORE: classic dependencies =====" SELECT vbeln, vkorg, netwr, waerk FROM vbak" WHERE vkorg = '1010' AND erdat = @sy-datum INTO TABLE @DATA(orders)." CALL FUNCTION 'NUMBER_GET_NEXT' EXPORTING nr_range_nr = '01' object = 'ZPR' ..." WRITE: / sy-uname. " ===== AFTER: released successors =====" 1. Table -> released CDS view (readable names, check semantics!)DATA(today) = cl_abap_context_info=>get_system_date( ).SELECT SalesOrder, SalesOrganization, TotalNetAmount, TransactionCurrency FROM i_salesorder WHERE SalesOrganization = '1010' AND CreationDate = @today INTO TABLE @DATA(orders). " 2. Number range FM -> released number range classTRY. cl_numberrange_runtime=>number_get( EXPORTING nr_range_nr = '01' object = 'ZPR' IMPORTING number = DATA(next_number) ). CATCH cx_number_ranges INTO DATA(nr_error). " handle / reportENDTRY. " 3. sy-uname -> released context classDATA(user) = cl_abap_context_info=>get_user_technical_name( ). " 4. HTTP call -> released HTTP client via destination" DATA(dest) = cl_http_destination_provider=>create_by_comm_arrangement( ... )." DATA(client) = cl_web_http_client_manager=>create_by_http_destination( dest ). " ===== Remediation list (keep it in the repository) =====" Object | Old dependency | Successor | Status" ZCL_PR_REPORT | VBAK | I_SalesOrder | done" ZCL_PR_REPORT | NUMBER_GET_NEXT | cl_numberrange_runtime | done" ZCL_PR_POSTING | BAPI_PR_CREATE | wrapper (tier 2) | openReal project scenario
A team ported a supplier evaluation report to ABAP Cloud and replaced LFA1 reads with I_Supplier in one afternoon. In testing, the number of suppliers differed: the report now excluded some one-time suppliers that the old table read had included.
Instead of reverting, they checked the CDS view's semantics, confirmed with the business that one-time suppliers were not relevant for evaluation, and documented the difference. For the remaining dependencies, they kept a remediation list and replaced one item per sprint, re-running ATC each time.
Common mistakes
- Replacing tables with CDS views without comparing results.
- Searching for successors by guessing names instead of using ADT/Hub/Cloudification Repository.
- Replacing everything in one big change.
- Keeping sy-uname/sy-datum in cloud code.
- Using wrappers where a released successor exists.
- Forgetting non-data dependencies: WRITE, SUBMIT, CALL TRANSACTION.
Best practices
- Start from ATC findings and a remediation list.
- Use ADT API state and successor information first.
- Compare old and new results with real data.
- Replace dependencies incrementally with tests.
- Record every wrapper with its intended future successor.
Interview angle
Questions: "How do you migrate classic code to ABAP Cloud?", "What replaces direct table access?", "Where do you find released successors?"
Strong answer: inventory dependencies via ATC; find successors via ADT API state, SAP Business Accelerator Hub and the Cloudification Repository; replace tables with released CDS views (checking semantics), BAPIs with released RAP interfaces/classes, sy fields with cl_abap_context_info, number ranges with cl_numberrange_runtime; use tier 2 wrappers only where no successor exists; migrate incrementally with tests.
Practice this lesson
Quick check
1. What is the typical released replacement for reading table VBAK in ABAP Cloud?
2. A clean-core extension on S/4HANA private cloud needs a BAPI that is not released. What is the recommended approach?
3. After replacing LFA1 with I_Supplier, a report shows fewer suppliers. What should the team do first?
Interview questions
1. Take a direct read of table LFA1 in custom code. How do you find and validate its cloud-ready replacement?
Answer it in your own words first, then compare.
2. How do you migrate a classic report that reads VBAK and calls a BAPI to ABAP Cloud?
Answer it in your own words first, then compare.
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
- ABAP Cloud Part 1: Released APIs, ATC and Clean Core
- ABAP Cloud Part 2: RAP and ABAP Cloud Architecture for Clean-Core Extensions
- ABAP Cloud Part 4: ATC Readiness — Finding and Fixing Unreleased Usage
- ABAP Cloud Part 5: On-Stack Developer Extension vs BTP Side-by-Side
- ABAP Cloud Part 6: Language Version, Syntax Restrictions and API Checks
- ABAP Cloud Part 7: Released APIs and Release Contracts