Lesson 1 of 6
Why syntax matters for ABAP Cloud
11 min
Listen to this lesson
Kenji learned ABAP on R/3 4.6C. Most of Contoso Motor Co.'s 7,500 in-scope custom objects were written in the same style: header lines, READ TABLE ... WITH KEY, MOVE, SELECT * into work areas, CONCATENATE, and lists written with WRITE. That code converted to SAP S/4HANA 2025 and still runs, because Standard ABAP keeps old statements for downward compatibility. So why should a team in the middle of a conversion care about modern syntax?
Three reasons. First, new extensions on Contoso's program are written in ABAP Cloud, using the restricted language version ABAP for Cloud Development. Some classic statements do not compile there at all. Second, modern expressions make code shorter and the intent clearer, which makes reviews and tests faster. Third, SAP's own examples, cheat sheets, generated RAP code and Clean ABAP guide are all written in modern syntax: a developer who cannot read it cannot use SAP's documentation.
Three kinds of "old"
| Kind | Meaning | Contoso example | What to do |
|---|---|---|---|
| Obsolete but allowed in Standard ABAP | Kept for compatibility; the keyword documentation says not to use it in new code | MOVE a TO b, header lines, DESCRIBE TABLE ... LINES | Replace when you touch the code |
| Not allowed in ABAP for Cloud Development | Syntax error in the restricted language version | WRITE lists, dynpros, MOVE, GET REFERENCE OF, BREAK-POINT | Must change before the object can move to ABAP Cloud |
| Allowed, but not released | The statement compiles; the object it uses is not a released API | SELECT from table KNA1 instead of a released CDS view | Use released APIs; covered in the ABAP Cloud course |
The difference matters: obsolete code still compiles in Standard ABAP; disallowed code fails in ABAP for Cloud Development.
SAP's ABAP cheat sheet for ABAP for Cloud Development shows examples that fail in the restricted version: MOVE num3 TO num1 (use the assignment num1 = num3), DESCRIBE TABLE itab LINES n (use lines( itab )), GET REFERENCE OF (use REF #( )), WRITE (implement if_oo_adt_classrun~main and call out->write( )), BREAK-POINT, classic sy-datum and sy-uzeit (use XCO or cl_abap_context_info), dynpros and executable programs. Reading the list once explains why classic developers hit dozens of syntax errors on their first ABAP Cloud class.
What modern ABAP looks like
One example from Contoso's legacy core return report shows the shift. The classic version reads open agreements into a table with a header line, loops, reads the customer name with READ TABLE ... WITH KEY, checks sy-subrc, and appends to an output table: about 25 lines. The modern version reads the agreements with joined customer names from released CDS views in one SELECT, uses FILTER for open ones, and builds the output with VALUE #( FOR ... ): about 8 lines, all of which state what the code does.
| Task | Classic | Modern |
|---|---|---|
| Declare and fill a variable | DATA lv_total TYPE p. then lv_total = ... | DATA(total) = ... |
| Read one row | READ TABLE lt_agr INTO ls_agr WITH KEY id = lv_id. then check sy-subrc | DATA(agr) = agreements[ id = agr_id ]. |
| Count rows | DESCRIBE TABLE lt_agr LINES lv_n. | DATA(n) = lines( agreements ). |
| Build text | CONCATENATE 'Deposit' lv_amt INTO lv_txt SEPARATED BY space. | DATA(text) = |Deposit { amount }|. |
| Copy fields | MOVE-CORRESPONDING ls_src TO ls_tgt. | tgt = CORRESPONDING #( src ). |
Where Contoso stands
After the conversion, Kenji's team runs ATC with the ABAP Cloud readiness checks on every object they change. Of the 7,500 in-scope objects, most will stay classic for years, and that is acceptable for code that is not touched. The rule is about change: when an object is touched for a defect or an enhancement, the changed lines are written in modern syntax, and if the object is moving to ABAP Cloud, every statement the restricted version rejects is replaced. Modern syntax is not a rewrite program; it is how changed code is written from now on.
What goes wrong
- "Modernize everything" projects. Mass syntax rewrites of untouched code create regression risk with no business benefit.
- Half-modern code. A method that mixes header lines and table expressions is harder to read than either style.
- Clever expressions. A
REDUCEnested three levels deep is modern and unreadable. Clarity is the goal. - Syntax without tests. Refactoring a
READ TABLEinto a table expression changes behavior when the row is missing (lesson 4). Without a test, nobody notices.
What would you do?
Grace asks Kenji whether Contoso should run a project to convert all 7,500 custom objects to modern syntax before go-live. What should Kenji recommend?
- Obsolete statements still compile in Standard ABAP; some do not compile in ABAP for Cloud Development.
- Examples rejected in ABAP Cloud: MOVE, DESCRIBE TABLE ... LINES, GET REFERENCE OF, WRITE, BREAK-POINT, dynpros.
- Almost all modern syntax is available since ABAP 7.40; FINAL( ) is newer.
- Modernize code when it changes, with tests, not in a mass rewrite.
Check your understanding · not graded
Lesson check
1. What replaces DESCRIBE TABLE itab LINES n in ABAP for Cloud Development?
2. Why does converted classic code still run in SAP S/4HANA 2025?
3. How does a class produce console output in ABAP Cloud instead of WRITE?
4. Which statement best describes Contoso's modernization rule?
5. A SELECT from table KNA1 compiles in classic code. What is its problem in ABAP Cloud?