ABAP Cloud Part 6: Language Version, Syntax Restrictions and API Checks

📌 KEY POINTS
✅ Every ABAP object has a language version. "ABAP for Cloud Development" is the one used for ABAP Cloud.
✅ The syntax check itself enforces the rules: forbidden statements and unreleased objects are syntax errors, not just warnings.
✅ Classic UI and system statements (WRITE, SUBMIT, CALL TRANSACTION, dynpro) are not allowed. Use RAP, released classes and console output.
⚠️ You can use your own custom tables and objects freely. The restriction is on SAP objects that are not released.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 4 used ATC to find problems. This part explains the rule that produces many of them: the language version of each object.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE LANGUAGE VERSIONS

• Standard ABAP: the classic full language. Anything is allowed; nothing is checked for release.
• ABAP for Cloud Development: restricted syntax plus a release check. Only released SAP APIs and your own objects may be used. This is ABAP Cloud.
• ABAP for Key Users: used by key-user tools (e.g. custom logic in Fiori apps); even more restricted.

In the SAP BTP ABAP environment and S/4HANA Cloud Public Edition, developer objects are always ABAP for Cloud Development. In S/4HANA on-premise and Private Cloud you choose per software component or package.

━━━━━━━━━━━━━━━━━━━━
▶ 2. WHERE IT IS SET

• In ADT: object → Properties → General → ABAP Language Version.
• Usually inherited: the software component or package is set up for ABAP Cloud, so every new object gets the cloud version automatically.
• Mixed packages are a warning sign; keep ABAP Cloud code in dedicated packages.

2a. HOW THE CHECK WORKS
When an object is ABAP for Cloud Development, the ABAP compiler checks each statement and each referenced repository object. Using an unreleased SAP table, class or function module gives a syntax error such as "not released for use in cloud development". ATC adds further checks, but the core rule is enforced at compile time.

━━━━━━━━━━━━━━━━━━━━
▶ 3. WHAT IS NOT ALLOWED (TYPICAL)

• Classic list and screen programming: WRITE, dynpro screens, selection screens, SUBMIT, CALL TRANSACTION.
• Native and dynamic access to SAP internals: EXEC SQL, direct access to SAP tables that are not released.
• Unreleased function modules, classes, BAdIs and system fields restricted in cloud (e.g. some sy fields).
• File system and OS access from the application server.
• Dynamic generation of programs (GENERATE SUBROUTINE POOL and similar).

━━━━━━━━━━━━━━━━━━━━
▶ 4. WHAT TO USE INSTEAD

• Output: console classes (IF_OO_ADT_CLASSRUN) for tests, RAP services and Fiori apps for users.
• User and time: CL_ABAP_CONTEXT_INFO for user, date and time.
• Number ranges: CL_NUMBERRANGE_RUNTIME.
• Background processing: application jobs (released job catalog/templates) or bgPF instead of SUBMIT/job FMs.
• Reading SAP data: released I_ CDS views and released RAP BO interfaces.
• Utilities: the XCO library (XCO_CP_*) for many generic needs.

━━━━━━━━━━━━━━━━━━━━
▶ 5. SWITCHING AN EXISTING OBJECT
Changing old code to ABAP for Cloud Development usually produces many syntax errors at once. Plan it as a migration: fix dependencies first (Part 3), then switch the version, then run ATC. Do not switch productive objects without regression tests.

💡 TIP: Create a small ABAP Cloud "playground" package and try each forbidden statement once. Seeing the actual syntax errors makes the rules stick.
⚠️ WATCH OUT: Released status is per contract. An object released for key-user use is not automatically released for cloud development, and the reverse is also true.
📌 REMEMBER: Language version decides what the compiler accepts. Release state decides which SAP objects you may call.

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

1. Create package ZPR_CLOUD with the ABAP Cloud language version (or in a cloud software component).
2. Create class ZCL_PR_DEMO implementing IF_OO_ADT_CLASSRUN.
3. Add a WRITE statement and a SELECT on a classic table; activate and read the errors.
4. Replace them with the cloud-compliant code shown in the example; activate again.
5. Run ATC with the cloud development variant to confirm zero findings.

✅ CHECKPOINT: you can tell which language version an object uses and rewrite classic statements into ABAP Cloud style.

A team switched 60 existing classes to ABAP for Cloud Development in one transport because "ATC showed only a few findings per class". Activation failed with hundreds of syntax errors, the transport was blocked and a release date slipped.
They restarted with a plan: replace dependencies per class first, switch one class at a time, activate, run unit tests and ATC, then move on. New development went into a dedicated cloud package from day one, so the migration backlog stopped growing.

• Thinking the cloud rules are only ATC warnings; they are syntax errors.
• Mixing Standard ABAP and ABAP Cloud objects in the same package.
• Assuming your own Z tables are forbidden (they are allowed).
• Switching many old objects at once without fixing dependencies first.
• Using sy-uname or sy-datum where released classes are required.

• Keep ABAP Cloud code in dedicated packages or software components.
• Migrate old objects one at a time: dependencies first, then the version switch.
• Use released classes (CL_ABAP_CONTEXT_INFO, XCO) instead of system fields and FMs.
• Run ATC with the cloud development variant on every change.
• Keep a small playground package for trying out the rules.

Questions: "What is an ABAP language version?", "What is not allowed in ABAP Cloud?", "How do you get the current user in ABAP Cloud?"
Strong answer: each object has a language version; ABAP for Cloud Development restricts syntax and only allows released SAP objects plus your own, enforced by the compiler. Classic UI statements, SUBMIT/CALL TRANSACTION, native SQL and unreleased objects are blocked. Alternatives: console output via IF_OO_ADT_CLASSRUN, CL_ABAP_CONTEXT_INFO for user/date, released I_ CDS views, application jobs or bgPF for background work.